57e58c3aa7
things fixed in here, including the '-ko' vs. -A problem with remote cvs which caused all files with -ko to be resent each time (which is damn painful over a modem, I can tell you). It also found a heap of stray empty directories that should have been pruned with the -P flag to cvs update but were not for some reason. It also has the fully integrated rcs and diff, so no more fork/exec overheads for rcs,ci,patch,diff,etc. This means that it parses the control data in the rcs files only once rather than twice or more. If the 'cvs diff' vs. Index thing is going to be fixed for future patch compatability, this is the place to do it.
62 lines
2.8 KiB
Plaintext
62 lines
2.8 KiB
Plaintext
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).
|
|
|
|
* (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.
|
|
(This reportedly happens if "cvs add CVS" (or "cvs add *")
|
|
is followed by "cvs status", in client/server mode - CVS 1.9).
|
|
|
|
* 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?
|