125839SpeterLow-priority bugs go here. Actually, most every documented bug is 225839Speter"low-priority"--in the sense that if it is documented it means noone 325839Speterhas gotten around to fixing it. 417721Speter 517721Speter 625839Speter* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the 725839Speter '-ko', at least in client/server mode. A simple work around is to 825839Speter temporarily change the db file with "cvs admin -ko file", then switch 925839Speter it back to the original modes after the checkout (probably '-kkv'). 1017721Speter 1125839Speter* "cvs status" has a difference in its output between local and 1225839Speter client/server mode. Namely there's a tab character followed by a 1325839Speter ctime(3)-style date string at the end of the "Working revision:" 1425839Speter field. 1517721Speter 1625839Speter* commands which don't work in a local working directory should probably 1725839Speter ignore any CVS/Root values and revert to using CVSROOT alone. The 1825839Speter current use of CVS/Root can be very confusing if you forget you're in 1925839Speter a working directory for a remote module -- something that's very easy 2025839Speter to do since CVS hides the client operation very well, esp. for 2125839Speter commands which fail for this reason. The only clue might be the word 2225839Speter "server" in a message such as this: 2325839Speter cvs server: cannot find module `patch' - ignored 2425839Speter 2525839Speter* cvs init may gave a strange error at times: 2625839Speter ttyp4:<woods@clapton> $ cvs -d /local/src-CVS init 2725839Speter cvs [init aborted]: cannot open CVS/Root: No such file or directory 2825839Speter but it seemed to work just the same.... Note that at the time CVSROOT 2925839Speter was set to point to a CVS server using the ":server:" option. 3025839Speter 3125839Speter* If a ~/CVS/Root file exists on the server and you are using rsh to 3225839Speterconnect to the server, CVS may loose its mind (this was reported in 3325839SpeterMay 1995 and I suspect the symptoms have changed, but I have no 3425839Speterparticular reason to think the bug is fixed -kingdon, Sep 96). 3525839Speter 3617721Speter* (Jeff Johnson <jbj@jbj.org>) 3717721Speter I tried a "cvs status -v" and received the following: 3817721Speter 3917721Speter ? CVS 4017721Speter ? programs/CVS 4117721Speter ? tests/CVS 4217721Speter cvs server: Examining . 4317721Speter =================================================================== 4417721Speter File: Install.dec Status: Up-to-date 4517721Speter ... 4617721Speter 4717721Speter I claim that CVS dirs should be ignored. 4832785Speter (This reportedly happens if "cvs add CVS" (or "cvs add *") 4932785Speter is followed by "cvs status", in client/server mode - CVS 1.9). 5017721Speter 5117721Speter* On remote checkout, files don't have the right time/date stamps in 5217721Speter the CVS/Entries files. Doesn't look like the C/S protocol has any 5317721Speter way to send this information along (according to cvsclient.texi). 5417721Speter Perhaps we can spiff it up a bit by using the conflict field for the 5517721Speter stamp on the checkout/update command. Please note that this really 5617721Speter doesn't do very much for us even if we get it done. 5717721Speter 5817721Speter* Does the function that lists the available modules in the repository 5917721Speter belong under the "checkout" function? Perhaps it is more logically 6017721Speter grouped with the "history" function or we should create a new "info" 6117721Speter function? 62