1997-05-15 22:46:24 +00:00
|
|
|
Low-priority bugs go here. Actually, most every documented bug is
|
|
|
|
|
"low-priority"--in the sense that if it is documented it means noone
|
|
|
|
|
has gotten around to fixing it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the
|
|
|
|
|
'-ko', at least in client/server mode. A simple work around is to
|
|
|
|
|
temporarily change the db file with "cvs admin -ko file", then switch
|
|
|
|
|
it back to the original modes after the checkout (probably '-kkv').
|
|
|
|
|
|
|
|
|
|
* "cvs status" has a difference in its output between local and
|
|
|
|
|
client/server mode. Namely there's a tab character followed by a
|
|
|
|
|
ctime(3)-style date string at the end of the "Working revision:"
|
|
|
|
|
field.
|
|
|
|
|
|
|
|
|
|
* commands which don't work in a local working directory should probably
|
|
|
|
|
ignore any CVS/Root values and revert to using CVSROOT alone. The
|
|
|
|
|
current use of CVS/Root can be very confusing if you forget you're in
|
|
|
|
|
a working directory for a remote module -- something that's very easy
|
|
|
|
|
to do since CVS hides the client operation very well, esp. for
|
|
|
|
|
commands which fail for this reason. The only clue might be the word
|
|
|
|
|
"server" in a message such as this:
|
|
|
|
|
cvs server: cannot find module `patch' - ignored
|
|
|
|
|
|
|
|
|
|
* cvs init may gave a strange error at times:
|
|
|
|
|
ttyp4:<woods@clapton> $ cvs -d /local/src-CVS init
|
|
|
|
|
cvs [init aborted]: cannot open CVS/Root: No such file or directory
|
|
|
|
|
but it seemed to work just the same.... Note that at the time CVSROOT
|
|
|
|
|
was set to point to a CVS server using the ":server:" option.
|
|
|
|
|
|
|
|
|
|
* If a ~/CVS/Root file exists on the server and you are using rsh to
|
|
|
|
|
connect to the server, CVS may loose its mind (this was reported in
|
|
|
|
|
May 1995 and I suspect the symptoms have changed, but I have no
|
|
|
|
|
particular reason to think the bug is fixed -kingdon, Sep 96).
|
1996-08-20 23:46:10 +00:00
|
|
|
|
|
|
|
|
* (Jeff Johnson <jbj@jbj.org>)
|
|
|
|
|
I tried a "cvs status -v" and received the following:
|
|
|
|
|
|
|
|
|
|
? CVS
|
|
|
|
|
? programs/CVS
|
|
|
|
|
? tests/CVS
|
|
|
|
|
cvs server: Examining .
|
|
|
|
|
===================================================================
|
|
|
|
|
File: Install.dec Status: Up-to-date
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
I claim that CVS dirs should be ignored.
|
1998-01-26 03:09:57 +00:00
|
|
|
(This reportedly happens if "cvs add CVS" (or "cvs add *")
|
|
|
|
|
is followed by "cvs status", in client/server mode - CVS 1.9).
|
1996-08-20 23:46:10 +00:00
|
|
|
|
|
|
|
|
* On remote checkout, files don't have the right time/date stamps in
|
|
|
|
|
the CVS/Entries files. Doesn't look like the C/S protocol has any
|
|
|
|
|
way to send this information along (according to cvsclient.texi).
|
|
|
|
|
Perhaps we can spiff it up a bit by using the conflict field for the
|
|
|
|
|
stamp on the checkout/update command. Please note that this really
|
|
|
|
|
doesn't do very much for us even if we get it done.
|
|
|
|
|
|
|
|
|
|
* Does the function that lists the available modules in the repository
|
|
|
|
|
belong under the "checkout" function? Perhaps it is more logically
|
|
|
|
|
grouped with the "history" function or we should create a new "info"
|
|
|
|
|
function?
|
