* `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.
