Remove CVS from the base system.

Discussed with:	many
Reviewed by:	peter, zi
Approved by:	core

1 files changed, 0 insertions, 61 deletions

diff --git a/contrib/cvs/MINOR-BUGS b/contrib/cvs/MINOR-BUGS
deleted file mode 100644
index 9eb0e7b..0000000
--- a/contrib/cvs/MINOR-BUGS
+++ /dev/null
@@ -1,61 +0,0 @@
-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:
-
-  ? CVS
-  ? programs/CVS
-  ? tests/CVS
-  cvs server: Examining .
-  ===================================================================
-  File: Install.dec            Status: Up-to-date
-  ...
-  
-  I claim that CVS dirs should be ignored.
-  (This reportedly happens if "cvs add CVS" (or "cvs add *")
-  is followed by "cvs status", in client/server mode - CVS 1.9).
-
-* 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?