To report bugs send mail to bug-cvs@prep.ai.mit.edu, or run the "cvsbug" program and fill out the template: $ cvsbug 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. * `cvs checkout -d nested/dir/path ' just doesn't work. The simpler version -- `cvs checkout -d single-dir ' 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 To: Cyclic CVS Hackers 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 ) 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" 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" 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" 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" 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 To: Cyclic CVS Hackers 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.