Import of cvs-1.9.9-970515 onto vendor branch.

Obtained from: cyclic.com

1 files changed, 91 insertions, 131 deletions

diff --git a/contrib/cvs/BUGS b/contrib/cvs/BUGS
index fc6af32..2a1c860 100644
--- a/contrib/cvs/BUGS
+++ b/contrib/cvs/BUGS
@@ -1,15 +1,50 @@
-To report bugs send mail to bug-cvs@prep.ai.mit.edu, or run the "cvsbug"
-program and fill out the template:
+See the README file for information on how to report bugs (and what
+will happen to your bug reports if you do).
 
-	$ cvsbug
+The following is a list of some of the known bugs.  It may or may not
+be comprehensive.  We would dearly love for people to volunteer to
+help us keep it up to date (for starters, if you notice any
+inaccuracies, please let bug-cvs know as described in README).  There
+are some other reported bugs in MINOR-BUGS; the difference, at least
+in theory, is that those bugs are less serious.
 
-The "cvsbug" program is installed in the same location as the "cvs"
-program.  If your installation failed, you may need to run "cvsbug"
-directly out of the "src" directory as "src/cvsbug.sh".  This is also
-the procedure for submitting suggested changes to CVS--note that all
-submitted changes may be distributed under the terms of the GNU Public
-License, so if you don't like this, don't submit them.
 
+* For platform-specific information (in some cases including known
+bugs), see README.VMS, windows-NT/README, or os2/README.  There is no
+similar file for the unix-like operating systems (not yet, at least).
+This file also might contain some platform-specific bugs.
+
+
+* Some people have reported seeing the message "dying gasps from %s
+unexpected" (where %s is the name of your server) when using
+client/server CVS.  One person reported that this had to do with using
+pserver and trying to run a program not in the PATH (which is set up
+by inetd, I think) from one of the *info scripts.  But noone has
+carefully tracked this down (is it caused by something in the server
+writing to stdout or stderr when it shouldn't?  But then wouldn't the
+"dying gasps" message be preceded by "warning: unrecognized response
+`%s' from cvs server"?).
+
+
+* "make remotecheck" sometimes fails on test 187a3 with
+    cvs server: in directory .:
+    cvs [server aborted]: *PANIC* administration files missing
+This does not happen every time.  (-kingdon, Nov 96, Red Hat linux 3.0.3).
+
+
+* The -m option to "cvs add" does not work with client/server CVS.
+CVS will accept the option, but it won't actually set the
+file's description.
+
+
+* cvs update walks into a user's work directory if there's a directory
+  of the same name in the repository even if the user's directory
+  doesn't yet have a CVS admin sub-directory.  This can greatly confuse
+  users who try to add the same directory at nearly the same time.
+
+
+* 'cvs admin' dumped core when files were missing from working directory
+  (and from the repository)?
 
 
 * `cvs checkout -d nested/dir/path <module>' just doesn't work.  The
@@ -17,9 +52,23 @@ License, so if you don't like this, don't submit them.
   however.
 
 
-* CVS leaves .#mumble files around when a conflict occurs.  (Note:
-  this is intentional and is documented in doc/cvs.texinfo.  Of course
-  whether it is a good idea is a separate question).
+* The following bug was reported against CVS 1.9:
+
+    Create a module named test with a file named test in it.
+
+      cactus:sfavor> cvs get test
+      cvs checkout: Updating test
+      U test/test
+      cactus:sfavor> cd test
+      cactus:sfavor> cvs get test
+      cvs checkout: cannot chdir to test: Not a directory
+      cvs checkout: ignoring module test
+      Exit 1
+      cactus:sfavor> cvs update
+      cvs update: Updating .
+      rcs.c:2139: failed assertion `rev == NULL || isdigit (*rev)'
+      Abort (core dumped)
+      Exit 134
 
 
 * pcl-cvs doesn't like it when you try to check in a file which isn't
@@ -27,6 +76,36 @@ License, so if you don't like this, don't submit them.
   what pcl-cvs is looking for.
 
 
+* From: billr@mpd.tandem.com (Bill Robertson)
+  Subject: Problem with rtag and the -D option
+  Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)
+
+  I have been trying to use the -D option to specify a date for tagging, but
+  rtag does not recognize the -D option. It is documented to do so and I've
+  tested the use of -D with cvs update and cvs diff and it works fine there.
+
+* Defining RELATIVE_REPOS is said to not work with client/server CVS.
+
+* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
+  To: info-cvs@prep.ai.mit.edu
+  Subject: Still one more bug
+  Date: Sat, 25 Feb 1995 17:01:15 -0500
+  
+  mycroft@duality [1]; cd /usr/src/lib/libc
+  mycroft@duality [1]; cvs diff -c2 '-D1 day ago' -Dnow
+  cvs server: Diffing .
+  cvs server: Diffing DB
+  cvs [server aborted]: could not chdir to DB: No such file or directory
+  mycroft@duality [1];
+  
+  `DB' is an old directory, which no longer has files in it, and is
+  removed automatically when I use the `-P' option to checkout.
+  
+  This error doesn't occur when run locally.
+  
+  P.S.  Is anyone working on fixing these bugs?
+
+
 * From: Roland McGrath <roland@gnu.ai.mit.edu>
   To: Cyclic CVS Hackers <info-cvs@prep.ai.mit.edu>
   Subject: weird bug
@@ -119,125 +198,6 @@ License, so if you don't like this, don't submit them.
   ls: cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype/cvs-serv28978/dirent/cvs-serv28978/elf/cvs-serv28978/gnu/cvs-serv28978/gnulib/cvs-serv28978/grp/cvs-serv28978/hurd/cvs-serv28978/hurd/hurd/cvs-serv28978/inet/cvs-serv28978/inet/arpa/cvs-serv28978/inet/netinet[...]/cvs-serv28978/posix/cvs-serv28978/posix/glob/cvs-serv28978/posix/gnu/cvs-serv28978/posix/sys/cvs-serv28978/protocols/cvs-serv28978/pwd/cvs-serv28978/resolv/cvs-serv28978/resolv/arpa/cvs-serv28978/resolv/sys/cvs-serv28978/resource/cvs-serv28978/resource/sys/cvs-serv28978/rpc/cvs-serv28978/setjmp/cvs-serv28978/signal/cvs-serv28978/signal/sys/cvs-serv28978/socket/cvs-serv28978/socket: File name too long
   cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype/cvs-serv28978/dirent/cvs-serv28978/elf/cvs-serv28978/gnu/cvs-serv28978/gnulib/cvs-serv28978/grp/cvs-serv28978/hurd/cvs-serv28978/hurd/hurd/cvs-serv28978/inet/cvs-serv28978/inet/arpa/cvs-serv28978/inet/netinet[...]/cvs-serv28978/posix/glob/cvs-serv28978/posix/gnu/cvs-serv28978/posix/sys/cvs-serv28978/protocols/cvs-serv28978/pwd/cvs-serv28978/resolv/cvs-serv28978/resolv/arpa/cvs-serv28978/resolv/sys/cvs-serv28978/resource/cvs-serv28978/resource/sys/cvs-serv28978/rpc/cvs-serv28978/setjmp/cvs-serv28978/signal/cvs-serv28978/signal/sys/cvs-serv28978/socket/cvs-serv28978:
 
-
-* From: billr@mpd.tandem.com (Bill Robertson)
-  Subject: Problem with rtag and the -D option
-  Date: Fri, 17 Mar 1995 10:53:29 -0600 (CST)
-
-  I have been trying to use the -D option to specify a date for tagging, but
-  rtag does not recognize the -D option. It is documented to do so and I've
-  tested the use of -D with cvs update and cvs diff and it works fine there.
-  
-
-*         We need some version numbers really badly.  Are there some
-  (and Charles Hannum is just not including them in his reports), or do
-  we simply have no reliable way to distinguish between the various
-  versions of rCVS people on the list are running?
-  
-          Now that I think of it, version numbers present a problem when
-  people can update their sources anytime and rebuild.  I think the
-  solution is to increment a minor version number *every* time a bug is
-  fixed, so we can identify uniquely what someone is running when they
-  submit a report.  This implies recording the version increments in the
-  ChangeLog; that way we can just look to see where a particular version
-  lies in relation to the flow of changing code.
-  
-          Should we be doing same with Guppy?  I guess not -- it's only
-  important when you have people who are updating directly from your
-  development tree, which is the case with the remote-cvs folks.
-  
-          Thoughts?
-
-
-* (Charles Hannum <mycroft@ai.mit.edu>) has these bugs:
-
-  I just tossed remote CVS at a fairly large source tree that I already
-  had, and noticed a few problems:
-
-  1) server.c assumes that /usr/tmp is a valid default for the place to
-  store files uploaded from the client.  There are a number of systems
-  that now use /var/tmp.  These should probably be detected by autoconf.
-
-  2) The server deals rather ungracefully with the tmp directory
-  becoming full.
-
-  3) There's some oddness with relative paths in Repository files that
-  causes the directory prefix to be added twice; e.g. if I have CVSROOT
-  set to `machine:/this/dir', and I try to update in a directory whose
-  Repository file says `src/bin', the server looks in
-  `/this/dir/machine:/this/dir/src/bin'.
-
-* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
-  To: jimb@duality.gnu.ai.mit.edu, roland@duality.gnu.ai.mit.edu
-  Subject: Serious flaw in remote CVS
-  Date: Wed, 22 Feb 1995 20:54:36 -0500
-
-  I just found a major flaw in the current implementation.  Because the
-  sockets are not changed to non-blocking mode, write(2)s can hang.  In
-  some cases, this happens on both sides at the same time, with the
-  socket buffers full in both directions.  This causes a deadlock,
-  because both processes are stuck in I/O wait and thus never drain
-  their input queues.
-  
-  Until this is fixed, I can't use it.  I'll look at the problem myself
-  at some point, but I don't know when.
-  
-
-  From: "Charles M. Hannum" <mycroft@ai.mit.edu>
-  To: info-cvs@prep.ai.mit.edu
-  Cc: jimb@totoro.bio.indiana.edu
-  Subject: Re: forwarded message from Charles M. Hannum
-  Date: Wed, 22 Feb 1995 22:07:07 -0500
-  
-  FYI, this happened because the tmp directory on the server became
-  full.  Somehow the server started interpreting the files the client
-  was sending as commands, and started spewing tons of errors.
-  Apparently the errors are sent with blocking I/O, or something, and
-  thus allowed the deadlock to happen.
-
-
-* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
-  To: info-cvs@prep.ai.mit.edu
-  Subject: Regarding that relative path problem
-  Date: Thu, 23 Feb 1995 02:41:51 -0500
-
-  This is actually more serious.  If you have `bar.com:/foo' as your CVS
-  root directory, then:
-
-  1) When you check things out, the Repository files will contain
-  `/foo/...' (i.e. without the machine name), which makes little sense.
-
-  2) If you instead have a relative path, when the Repository file is
-  read, `bar.com:/foo' is prepended.  This is sent to the server, but
-  confuses it, because it's not expecting the machine name to be
-  prepended.
-
-  A slightly klugy fix would be to have the client prepend the machine
-  name when writing a new Repository file, and strip it off before
-  sending one to the server.  This would be backward-compatible with the
-  current arrangement.
-
-
-* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
-  To: info-cvs@prep.ai.mit.edu
-  Subject: Still one more bug
-  Date: Sat, 25 Feb 1995 17:01:15 -0500
-  
-  mycroft@duality [1]; cd /usr/src/lib/libc
-  mycroft@duality [1]; cvs diff -c2 '-D1 day ago' -Dnow
-  cvs server: Diffing .
-  cvs server: Diffing DB
-  cvs [server aborted]: could not chdir to DB: No such file or directory
-  mycroft@duality [1];
-  
-  `DB' is an old directory, which no longer has files in it, and is
-  removed automatically when I use the `-P' option to checkout.
-  
-  This error doesn't occur when run locally.
-  
-  P.S.  Is anyone working on fixing these bugs?
-
-
 * From: Roland McGrath <roland@gnu.ai.mit.edu>
   To: Cyclic CVS Hackers <info-cvs@prep.ai.mit.edu>
   Subject: bizarre failure mode