1 files changed, 36 insertions, 35 deletions
diff --git a/gnu/usr.bin/cvs/MINOR-BUGS b/gnu/usr.bin/cvs/MINOR-BUGS
index 7b857193f86..ba6fb182111 100644
--- a/gnu/usr.bin/cvs/MINOR-BUGS
+++ b/gnu/usr.bin/cvs/MINOR-BUGS
@@ -1,26 +1,37 @@
-Low-priority bugs go here.  We don't have many yet -- everything is
-high-priority at the moment. :-)
-
-
-* From: Jeff Johnson <jbj@brewster.JBJ.ORG>
-  To: cyclic-cvs@cyclic.com
-  Subject: Named_Root assumes . on server
-  Date: Wed, 17 May 1995 11:04:53 -0400 (EDT)
-  
-  Problem:
-  	On server, Name_Root() attempts (aggressively) to set CVSADM_Root.
-  	If ~/CVS/Root exists (wrto rsh login), then CVSADM_Root will be
-  	initialized from that file. The sanity check between the root
-  	repository and the invocation will fail if the two values are not
-  	coincidentally the same.
-  
-  Workaround:
-  	There's a zillion ways to fix this bugture/featurelet. My current
-  	workaround is to remove ~/CVS/Root on the server. I shall attempt
-  	a better fix as soon as I can determine what appears politically
-  	correct. IMHO, the CVS/Root stuff (and getenv("CVSROOT") also) is
-  	a bit fragile and tedious in an rcmd() driven CCVS environment.
-
+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:
@@ -34,18 +45,8 @@ high-priority at the moment. :-)
   ...
   
   I claim that CVS dirs should be ignored.
-
-
-* I sometimes get this message:
-
-  Could not look up address for your host.  Permission denied.
-  cvs [update aborted]: premature end of file from server
-
-  The client's response should be cleaned up.
-
-* In the gb-grep module, update-ChangeLog (and therefore, I assume,
-  rcs2log) truncates file names --- I get entries for things called
-  ring/lenstring.h instead of lenstring/lenstring.h.
+  (I don't *think* this always happens; is "-I !" getting picked up somewhere
+  something like that? -kingdon, Sep 96)
 
 * 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