raw import of cvs-1.6

1 files changed, 60 insertions, 0 deletions

diff --git a/gnu/usr.bin/cvs/MINOR-BUGS b/gnu/usr.bin/cvs/MINOR-BUGS
new file mode 100644
index 00000000000..7b857193f86
--- /dev/null
+++ b/gnu/usr.bin/cvs/MINOR-BUGS
@@ -0,0 +1,60 @@
+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.
+
+
+* (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.
+
+
+* 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.
+
+* 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?