They don't call it the bleeding edge for nothing

This page describes some of the known bugs in CVS. It is a relatively detailed list particularly aimed at the heavy CVS user and the CVS user who likes to download experimental versions of CVS. For a much shorter list of the biggest bugs in released versions of CVS, see our User-level Known Bugs page.

Even so, this page doesn't list all known bugs in CVS. Perhaps there will never be such a list.

Bugs not yet fixed in development versions of CVS

If the CVSROOT has a trailing slash, CVS 1.10 will tend to display pathnames like "/var/cvsroot//CVSROOT/modules,v" whereas CVS 1.9 would remove the extra slash. This will lead CVS to skip the "Rebuilding administrative file database" operation. This is #196 in TODO.

There have been some reports that checkins are 10x to 100x slower with CVS 1.10 instead of RCS 5.7, when the repository is mounted via NFS.

In part reports about error messages like "EOF in key in RCS file" are now addressed in the Cederqvist (Cederqvist change of 1999-04-08), but here is one report of a problem which seems like it may be a CVS bug.

Bugs fixed in development versions of CVS

CVS 1.10 or so through CVS 1.10.6 tends to lose its mind on symbolic links in the working directory (fix checked in 1999-06-23).

Trying to run "cvs login" with a CVS 1.10.6 server will abort with an error "recv() from server machine: EOF" (fix checked in 1999-05-20).

Bugs fixed in CVS 1.10.6

For CVS 1.5 through 1.10.5, the $Name keyword will sometimes fail to expand correctly for client/server CVS (fix checked in 1999-05-16).

For CVS 1.7 through 1.10.5, the CVS servers which switch users (kerberos, GSS-API, pserver) would not check for errors from the system when switching users. This has now been fixed (checked in 1999-05-11), which shouldn't affect anything except people who may be trying to run these servers as non-root users.

For CVS 1.9.20 through 1.10.5, running "cvs admin -n" or "cvs admin -N" to set a tag to a branch which doesn't already have a tag (e.g. "cvs admin -nbr:1.6.4") will give an erroneous error "revision `1.6.4' does not exist" (fix checked in 1999-05-10).

For CVS 1.10 (or so) through 1.10.5, on Windows (sometimes) and OS/2 (presumably), CVS tends to give an error such as "Permission denied" when there is a conflict. Fixed by Larry Jones checkin to diff/diff3.c on 1999-03-24. For older fixes of similar problems see "bugs fixed in CVS 1.10.3" below.

For CVS 1.9.20 through CVS 1.10.5, running "cvs admin -o" on a file containing a $Log keyword would corrupt the repository (fix checked in 1999-04-20).

Bugs fixed in CVS 1.10.5

For CVS 1.10.4 and older, if you run "cvs add -kb" on a file which previously existed as a text file, (the case where CVS prints "re-adding file file1 (in place of dead revision 1.2)"), the -kb will not take (fix checked in 1999-01-29). The workaround is "cvs admin -kb".

For CVS 1.9.20 through CVS 1.10.4, running "cvs admin -o" on a binary file would corrupt the repository (fix checked in 1999-02-08).

Bugs fixed in CVS 1.10.4

When deleting a tag, the specific file and revision had not been passed to the taginfo script in CVS 1.6 through 1.10.3 (fix checked in 1998-11-13).

Bugs fixed in CVS 1.10.3

If one has shared ,v files in the repository connected via symlinks (CVS doesn't create such symlinks, but CVS administrators may), then some things are still broken in CVS 1.9.29 through 1.10.2 (cvs tag, cvs rtag, and cvs admin, at least, maybe some cases in cvs commit too) (fix checked in 1998-09-24).

"cvs diff", if it is displaying differences for a file in a subdirectory, will now include the subdirectory name (checked in 1998-09-24).

For CVS 1.10 (and older?), trying to specify the revision number on the first checkin of a newly added file (for example "cvs add" then "cvs ci -r 1.3") would tend to produce a core dump (fix checked in 1998-10-11).

On OS/2, and sometimes on Windows, CVS 1.10 has some problems with CVS trying to operate on open files, and similar problems. One symptom is that checking in the addition of a new file can give a spurious warning such as "cvs commit: warning: cannot change mode of file,v: Permission denied" (fixed by Ian's checkin to remove fix_rcs_modes, 1998-08-17). Another symptom is a similar error when trying to move files into or out of the Attic (fix checked in 1998-08-25). Also see the 1998-09-28 fix to windows-NT/filesubr.c (concerning the ,v files being readonly). CVS 1.10.3 does not fix all such problems; see above for one involving conflicts. Setting DeleteReadOnly=yes for Samba is said to help, but I'm confused about why that would be needed (based on looking at the code).

Bugs fixed in CVS 1.10.1

There is a serious bug in "cvs release -d ." in CVS 1.3 (or so) through CVS 1.10, on non-unix operating systems. It will go *up* one directory level, and then remove all files and subdirectories. So this is a very bad bug, in the sense that the effect is pretty dire. On the other hand, if you don't happen to run "cvs release -d .", there is no problem. Fix checked in 1998-08-24.

Bugs fixed in CVS 1.10

Fixed a somewhat obscure core dump involving "cvs admin -l" and branches (fix checked in 1998-08-06).

Bugs fixed in CVS 1.9.29

If one has shared ,v files in the repository connected via symlinks (CVS doesn't create such symlinks, but CVS administrators may), then CVS 1.9.20 through 1.9.28 will not maintain the symlinks (partial fix was in CVS 1.9.29, checked in 28 Jul 1998; complete fix not checked in until 1998-09-24).

CVS directories at top level (fix was to add the TopLevelAdmin setting in CVSROOT/config, checked in 1998-07-26; discussion).

The testsuite fails in test modes2 on many platforms (fix checked in 1998-06-23).

If you try to add directories with a CVS 1.9.16 through 1.9.28 client and a CVS 1.9 server, it will fail with "cvs server: dir already exists, with version number" (fix checked in 4 Jun 1998).

Bugs fixed in CVS 1.9.28

CVS 1.9.27 will tend to fail on certain RCS files with an abort (the first abort in rcsbuf_getkey) (fix checked in 1998-05-02).

CVS 1.9.26 through 1.9.27 have a serious bug which can cause data loss if you are using -t/-f wrappers. The "fix" is to disable -t/-f wrappers (checked in 1998-05-20).

Bugs fixed in CVS 1.9.27

Year 2000 fix (checked in 1998-04-11).

CVS 1.3 (?) through 1.9.26 would tend to print out the wrong pathname if one specifies subdirectories on the CVS command (fix checked in 8 Apr 1998).

CVS 1.5 (?) through 1.9.24, client/server, would not correctly respect the user's (client's) umask in setting the permissions of files in the working directory (fix checked in 8 Feb 1998 and 1998-02-16).

CVS 1.9.20 through 1.9.26 had various bugs in handling RCS files, including cvs admin -l, cvs admin -n, $Log, temporary files, "too low" aborts. If you are running one of those versions, an upgrade to CVS 1.9.28 or so is recommended.

CVS 1.9.20 and older have known bugs with binary files on non-unix platforms. The known bugs have been fixed (but watch out for the known features - CVS still doesn't do everything that would be nice to have).

CVS 1.9.18 (?) through 1.9.26 have problems with absolute pathnames, for example "cvs update /foo/bar" (fix checked in by Noel Cragg on 17 Feb 1998, with fixes to the fix checked in by Jim Kingdon on 16 Apr 1998).

On Windows, non-client/server, CVS 1.9.18 and older will get confused if the log message contains a double quote (") (fix checked in 10 Nov 1997).

Bugs fixed in CVS 1.9.18

CVS 1.9.10 through 1.9.16 can give a spurious "duplicate Mod-time" error in certain cases involving errors and the -n global option (fixes checked in 25 Jul 1997 and 26 Sep 1997).

Bugs fixed in CVS 1.9.16

With CVS 1.3 (?) through 1.9.14, the "cvs -n release" command will dump core (or some such symptom). The fix was to make it print an error instead (checked in 30-Aug-97).

Bugs fixed in CVS 1.9.12

The CVS 1.9.10 (and older) client running on Windows has problems at reporting networking errors. Fixed in CVS 1.9.12 and later.

Bugs fixed in CVS 1.9.10

The CVS 1.9.8 (or older) pserver server has a security hole, see Security hole affects many CVS pserver installations. See that page for the fix.

When doing a commit, the CVS 1.9.10 and later pserver server will set the author field of the RCS file according to the user name specified to get access to CVS. Previous versions would show the commit as having been done by the user ID under which CVS is running (which will be different if so specified in CVSROOT/passwd) (fix checked in 29 May 1997).

Bugs fixed in CVS 1.9.8

CVS 1.9 has an incompatibility with some linux systems. If you got CVS as part of your linux system, this should be taken care of, either because the system is not affected or because it supplies a patched CVS. If you are building CVS yourself, or want more technical details, see this CVS 1.9 patch.

Bugs fixed in CVS 1.9.4

In CVS 1.9 and earlier, the CVSUMASK environment variable fails to affect repository permissions in some (somewhat obscure) cases (fix checked in 16 Mar 1997).

Bugs fixed in CVS 1.9.2

On Windows, using a UNC pathname (for example setting CVSROOT to ":local:\\machine\cvs") will not work with CVS 1.9 or older (fix checked in 19 Nov 1996).

With a CVS 1.9 or older server specifying & in the modules file checks the files out into the wrong directory (fix checked in 10 Oct 1996).

Bugs fixed in CVS 1.9

If you are looking for information on versions of CVS older than 1.9, this page won't help you much. The user-level page has a few brief notes.