1 files changed, 0 insertions, 60 deletions
diff --git a/gnu/usr.bin/cvs/MINOR-BUGS b/gnu/usr.bin/cvs/MINOR-BUGS
deleted file mode 100644
index 7b857193f86be..0000000000000
--- a/gnu/usr.bin/cvs/MINOR-BUGS
+++ /dev/null
@@ -1,60 +0,0 @@
-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?