101 lines
4.2 KiB
Plaintext
101 lines
4.2 KiB
Plaintext
|
See the Cederqvist manual (cvs.texinfo) for information on how to
|
||
|
|
report bugs (and what will happen to your bug reports if you do).
|
||
|
|
|
||
|
|
The following is a list of some of the known bugs. It may or may not
|
||
|
|
be comprehensive. We would dearly love for people to volunteer to
|
||
|
|
help us keep it up to date (for starters, if you notice any
|
||
|
|
inaccuracies, please let bug-cvs know as described in the Cederqvist
|
||
|
|
manual). There are some other reported bugs in MINOR-BUGS; the
|
||
|
|
difference, at least in theory, is that those bugs are less serious.
|
||
|
|
|
||
|
|
|
||
|
|
* For platform-specific information (in some cases including known
|
||
|
|
bugs), see README.VMS, windows-NT/README, or os2/README. There is no
|
||
|
|
similar file for the unix-like operating systems (not yet, at least).
|
||
|
|
This file also might contain some platform-specific bugs.
|
||
|
|
|
||
|
|
|
||
|
|
* If your login name contains a space or various other characters
|
||
|
|
(particularly an issue on Windows), CVS will have trouble (it will
|
||
|
|
write invalid RCS files, probably). The fix would be to have CVS
|
||
|
|
change such characters to underscores before writing them to the RCS
|
||
|
|
file. Furthermore, the LOGNAME or USER environment variables usually
|
||
|
|
won't override the system login name, so this can be hard to work
|
||
|
|
around.
|
||
|
|
|
||
|
|
|
||
|
|
* If you specify the -w global option to client/server CVS, it only
|
||
|
|
overrides a CVSREAD environment variable set on the client, not a
|
||
|
|
CVSREAD variable which was set on the server (for example, in .bashrc
|
||
|
|
when the server was run via rsh). The fix of course will be to
|
||
|
|
provide a "Option-read-write" request which sends -w, in addition to
|
||
|
|
"Global_option -r" which sends -r.
|
||
|
|
|
||
|
|
|
||
|
|
* Symbolic links to files will not work with or without LockDir. In the
|
||
|
|
repository, you should avoid using symbolic links to files since this issue
|
||
|
|
can cause data loss. Symlinks are only a problem when writing files. If your
|
||
|
|
repository does not allow any write access, symlinks are not a problem.
|
||
|
|
|
||
|
|
|
||
|
|
* Symbolic links to directories will not work with LockDir. In the
|
||
|
|
repository, you should avoid using symbolic links to directories if
|
||
|
|
you intend to use LockDir as the correct directory will NOT be locked
|
||
|
|
by CVS during write. Directory symlinks are not recommended, but should work
|
||
|
|
as long as LockDir is not being used. Symlinks are only a problem when
|
||
|
|
writing files. If your repository does not allow any write access, symlinks
|
||
|
|
are never a problem, whether or not LockDir is in use.
|
||
|
|
|
||
|
|
|
||
|
|
* The -m option to "cvs add" does not work with client/server CVS.
|
||
|
|
CVS will accept the option, but it won't actually set the
|
||
|
|
file's description.
|
||
|
|
|
||
|
|
|
||
|
|
* cvs update walks into a user's work directory if there's a directory
|
||
|
|
of the same name in the repository even if the user's directory
|
||
|
|
doesn't yet have a CVS admin sub-directory. This can greatly confuse
|
||
|
|
users who try to add the same directory at nearly the same time.
|
||
|
|
|
||
|
|
|
||
|
|
* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
|
||
|
|
To: info-cvs@prep.ai.mit.edu
|
||
|
|
Subject: Still one more bug
|
||
|
|
Date: Sat, 25 Feb 1995 17:01:15 -0500
|
||
|
|
|
||
|
|
mycroft@duality [1]; cd /usr/src/lib/libc
|
||
|
|
mycroft@duality [1]; cvs diff -C2 '-D1 day ago' -Dnow
|
||
|
|
cvs server: Diffing .
|
||
|
|
cvs server: Diffing DB
|
||
|
|
cvs [server aborted]: could not chdir to DB: No such file or directory
|
||
|
|
mycroft@duality [1];
|
||
|
|
|
||
|
|
`DB' is an old directory, which no longer has files in it, and is
|
||
|
|
removed automatically when I use the `-P' option to checkout.
|
||
|
|
|
||
|
|
This error doesn't occur when run locally.
|
||
|
|
|
||
|
|
P.S. Is anyone working on fixing these bugs?
|
||
|
|
|
||
|
|
|
||
|
|
* CVS does not always seem to be waiting to the next filesystem timestamp
|
||
|
|
quanta after commits. So far this has only shown up in testing under the BSDI
|
||
|
|
OS. The symptoms are that ocassionally CVS will not notice that modified files
|
||
|
|
are modified, though the file must be modified within a short time after the
|
||
|
|
commit, probably milliseconds or seconds, for this symptom to be noticed. One
|
||
|
|
suspected cause is that one of the calls to sleep_past() is being called with
|
||
|
|
an incorrect value, though this does not explain why symptoms have only been
|
||
|
|
noticed under BSDI.
|
||
|
|
|
||
|
|
|
||
|
|
* Status
|
||
|
|
|
||
|
|
/*-------.
|
||
|
|
| Stable |
|
||
|
|
`-------*/
|
||
|
|
|
||
|
|
/*-------------------------.
|
||
|
|
| Sane for full scale use. |
|
||
|
|
`-------------------------*/
|
||
|
|
|