raw import of cvs-1.6

1 files changed, 248 insertions, 0 deletions

diff --git a/gnu/usr.bin/cvs/BUGS b/gnu/usr.bin/cvs/BUGS
new file mode 100644
index 00000000000..3ad13a82828
--- /dev/null
+++ b/gnu/usr.bin/cvs/BUGS
@@ -0,0 +1,248 @@
+* `cvs checkout -d nested/dir/path <module>' just doesn't work.  The
+  simpler version -- `cvs checkout -d single-dir <module>' works,
+  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).
+
+
+* pcl-cvs doesn't like it when you try to check in a file which isn't
+  up-to-date.  The messages produced by the server perhaps don't match
+  what pcl-cvs is looking for.
+
+
+* From: Roland McGrath <roland@gnu.ai.mit.edu>
+  To: Cyclic CVS Hackers <cyclic-cvs@cyclic.com>
+  Subject: weird bug
+  Date: Sat, 25 Mar 1995 16:41:41 -0500
+  X-Windows: Even your dog won't like it.
+
+  I just noticed some droppings on my disk from what must be a pretty weird
+  bug in remote CVS.
+
+  In my home directory on a repository machine I use, I find:
+
+  drwxr-xr-x   4 roland   staff         512 Mar  7 14:08 cvs-serv28962
+  drwxr-xr-x   4 roland   staff         512 Mar  7 14:11 cvs-serv28978
+  drwxr-xr-x   4 roland   staff         512 Mar  7 15:13 cvs-serv29141
+
+  OK, so these are leftover cruft from some cvs run that got aborted.
+  Well, it should clean up after itself, but so what.
+
+  The last one is pretty dull; the real weirdness is the contents of the
+  first two directories.
+
+  duality 77 # ls -RF cvs-serv28978/
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/CVS:
+  Entries	    Repository
+
+  cvs-serv28978/cvs-serv28978:
+  arpa/
+
+  cvs-serv28978/cvs-serv28978/arpa:
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/cvs-serv28978/arpa/CVS:
+  Entries	    Repository
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978:
+  assert/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert:
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/CVS:
+  Entries	    Repository
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978:
+  bare/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare:
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/CVS:
+  Entries	    Repository
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978:
+  conf/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf:
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/CVS:
+  Entries	    Repository
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978:
+  crypt/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt:
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/CVS:
+  Entries	    Repository
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978:
+  csu/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu:
+  CVS/		cvs-serv28978/
+
+  cvs-serv28978/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/CVS:
+  Entries	    Repository
+
+  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/cvs-serv28978/arpa/cvs-serv28978/assert/cvs-serv28978/bare/cvs-serv28978/conf/cvs-serv28978/crypt/cvs-serv28978/csu/cvs-serv28978/ctype:
+  CVS/		cvs-serv28978/
+
+  [...]
+
+  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: remote-cvs@cyclic.com
+  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: remote-cvs@cyclic.com
+  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: remote-cvs@cyclic.com
+  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 <cyclic-cvs@cyclic.com>
+  Subject: bizarre failure mode
+  Date: Tue, 7 Mar 95 14:17:28 -0500
+  
+  This is pretty weird:
+  
+  CVS_SERVER='TMPDIR=. /usr/local/bin/cvs' ../cvs-build/src/cvs update -q
+  cvs [server aborted]: could not get working directory: Result too large
+  [Exit 1]
+  asylum 29 % grep 'Result too large' /usr/include/sys/errno.h 
+  #define ERANGE          34              /* Result too large */
+  
+  Now, getcwd fails with ERANGE when the buffer is too small.  But I don't
+  know why that would be the case; I don't think there are exceptionally long
+  directory names involved.  It would be robust to notice ERANGE and use a
+  bigger buffer.  But I suspect something weirder is going on.
+  
+  The repository in question in duality.gnu.ai.mit.edu:/gd4/gnu/cvsroot/libc.
+  
+  Send me a PGP-signed message if you want the password to use the machine
+  where the problem showed up.