150bf276cStholoLow-priority bugs go here. Actually, most every documented bug is 250bf276cStholo"low-priority"--in the sense that if it is documented it means noone 350bf276cStholohas gotten around to fixing it. 41e72d8d2Sderaadt 51e72d8d2Sderaadt 650bf276cStholo* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the 750bf276cStholo '-ko', at least in client/server mode. A simple work around is to 850bf276cStholo temporarily change the db file with "cvs admin -ko file", then switch 950bf276cStholo it back to the original modes after the checkout (probably '-kkv'). 101e72d8d2Sderaadt 1150bf276cStholo* "cvs status" has a difference in its output between local and 1250bf276cStholo client/server mode. Namely there's a tab character followed by a 1350bf276cStholo ctime(3)-style date string at the end of the "Working revision:" 1450bf276cStholo field. 151e72d8d2Sderaadt 1650bf276cStholo* commands which don't work in a local working directory should probably 1750bf276cStholo ignore any CVS/Root values and revert to using CVSROOT alone. The 1850bf276cStholo current use of CVS/Root can be very confusing if you forget you're in 1950bf276cStholo a working directory for a remote module -- something that's very easy 2050bf276cStholo to do since CVS hides the client operation very well, esp. for 2150bf276cStholo commands which fail for this reason. The only clue might be the word 2250bf276cStholo "server" in a message such as this: 2350bf276cStholo cvs server: cannot find module `patch' - ignored 241e72d8d2Sderaadt 2550bf276cStholo* cvs init may gave a strange error at times: 2650bf276cStholo ttyp4:<woods@clapton> $ cvs -d /local/src-CVS init 2750bf276cStholo cvs [init aborted]: cannot open CVS/Root: No such file or directory 2850bf276cStholo but it seemed to work just the same.... Note that at the time CVSROOT 2950bf276cStholo was set to point to a CVS server using the ":server:" option. 3050bf276cStholo 3150bf276cStholo* If a ~/CVS/Root file exists on the server and you are using rsh to 3250bf276cStholoconnect to the server, CVS may loose its mind (this was reported in 3350bf276cStholoMay 1995 and I suspect the symptoms have changed, but I have no 3450bf276cStholoparticular reason to think the bug is fixed -kingdon, Sep 96). 351e72d8d2Sderaadt 361e72d8d2Sderaadt* (Jeff Johnson <jbj@jbj.org>) 371e72d8d2Sderaadt I tried a "cvs status -v" and received the following: 381e72d8d2Sderaadt 391e72d8d2Sderaadt ? CVS 401e72d8d2Sderaadt ? programs/CVS 411e72d8d2Sderaadt ? tests/CVS 421e72d8d2Sderaadt cvs server: Examining . 431e72d8d2Sderaadt =================================================================== 441e72d8d2Sderaadt File: Install.dec Status: Up-to-date 451e72d8d2Sderaadt ... 461e72d8d2Sderaadt 471e72d8d2Sderaadt I claim that CVS dirs should be ignored. 48*2286d8edStholo (This reportedly happens if "cvs add CVS" (or "cvs add *") 49*2286d8edStholo is followed by "cvs status", in client/server mode - CVS 1.9). 501e72d8d2Sderaadt 511e72d8d2Sderaadt* On remote checkout, files don't have the right time/date stamps in 521e72d8d2Sderaadt the CVS/Entries files. Doesn't look like the C/S protocol has any 531e72d8d2Sderaadt way to send this information along (according to cvsclient.texi). 541e72d8d2Sderaadt Perhaps we can spiff it up a bit by using the conflict field for the 551e72d8d2Sderaadt stamp on the checkout/update command. Please note that this really 561e72d8d2Sderaadt doesn't do very much for us even if we get it done. 571e72d8d2Sderaadt 581e72d8d2Sderaadt* Does the function that lists the available modules in the repository 591e72d8d2Sderaadt belong under the "checkout" function? Perhaps it is more logically 601e72d8d2Sderaadt grouped with the "history" function or we should create a new "info" 611e72d8d2Sderaadt function? 62