1*a7c91847SchristosLow-priority bugs go here. Actually, most every documented bug is 2*a7c91847Schristos"low-priority"--in the sense that if it is documented it means noone 3*a7c91847Schristoshas gotten around to fixing it. 4*a7c91847Schristos 5*a7c91847Schristos 6*a7c91847Schristos* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the 7*a7c91847Schristos '-ko', at least in client/server mode. A simple work around is to 8*a7c91847Schristos temporarily change the db file with "cvs admin -ko file", then switch 9*a7c91847Schristos it back to the original modes after the checkout (probably '-kkv'). 10*a7c91847Schristos 11*a7c91847Schristos* "cvs status" has a difference in its output between local and 12*a7c91847Schristos client/server mode. Namely there's a tab character followed by a 13*a7c91847Schristos ctime(3)-style date string at the end of the "Working revision:" 14*a7c91847Schristos field. 15*a7c91847Schristos 16*a7c91847Schristos* commands which don't work in a local working directory should probably 17*a7c91847Schristos ignore any CVS/Root values and revert to using CVSROOT alone. The 18*a7c91847Schristos current use of CVS/Root can be very confusing if you forget you're in 19*a7c91847Schristos a working directory for a remote module -- something that's very easy 20*a7c91847Schristos to do since CVS hides the client operation very well, esp. for 21*a7c91847Schristos commands which fail for this reason. The only clue might be the word 22*a7c91847Schristos "server" in a message such as this: 23*a7c91847Schristos cvs server: cannot find module `patch' - ignored 24*a7c91847Schristos 25*a7c91847Schristos* cvs init may gave a strange error at times: 26*a7c91847Schristos ttyp4:<woods@clapton> $ cvs -d /local/src-CVS init 27*a7c91847Schristos cvs [init aborted]: cannot open CVS/Root: No such file or directory 28*a7c91847Schristos but it seemed to work just the same.... Note that at the time CVSROOT 29*a7c91847Schristos was set to point to a CVS server using the ":server:" option. 30*a7c91847Schristos 31*a7c91847Schristos* If a ~/CVS/Root file exists on the server and you are using rsh to 32*a7c91847Schristosconnect to the server, CVS may loose its mind (this was reported in 33*a7c91847SchristosMay 1995 and I suspect the symptoms have changed, but I have no 34*a7c91847Schristosparticular reason to think the bug is fixed -kingdon, Sep 96). 35*a7c91847Schristos 36*a7c91847Schristos* (Jeff Johnson <jbj@jbj.org>) 37*a7c91847Schristos I tried a "cvs status -v" and received the following: 38*a7c91847Schristos 39*a7c91847Schristos ? CVS 40*a7c91847Schristos ? programs/CVS 41*a7c91847Schristos ? tests/CVS 42*a7c91847Schristos cvs server: Examining . 43*a7c91847Schristos =================================================================== 44*a7c91847Schristos File: Install.dec Status: Up-to-date 45*a7c91847Schristos ... 46*a7c91847Schristos 47*a7c91847Schristos I claim that CVS dirs should be ignored. 48*a7c91847Schristos (This reportedly happens if "cvs add CVS" (or "cvs add *") 49*a7c91847Schristos is followed by "cvs status", in client/server mode - CVS 1.9). 50*a7c91847Schristos 51*a7c91847Schristos* On remote checkout, files don't have the right time/date stamps in 52*a7c91847Schristos the CVS/Entries files. Doesn't look like the C/S protocol has any 53*a7c91847Schristos way to send this information along (according to cvsclient.texi). 54*a7c91847Schristos Perhaps we can spiff it up a bit by using the conflict field for the 55*a7c91847Schristos stamp on the checkout/update command. Please note that this really 56*a7c91847Schristos doesn't do very much for us even if we get it done. 57*a7c91847Schristos 58*a7c91847Schristos* Does the function that lists the available modules in the repository 59*a7c91847Schristos belong under the "checkout" function? Perhaps it is more logically 60*a7c91847Schristos grouped with the "history" function or we should create a new "info" 61*a7c91847Schristos function? 62