summaryrefslogtreecommitdiffstats
path: root/contrib/cvs/MINOR-BUGS
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/cvs/MINOR-BUGS')
-rw-r--r--contrib/cvs/MINOR-BUGS61
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?
OpenPOWER on IntegriCloud