diff options
Diffstat (limited to 'gnu/usr.bin/cvs/BUGS')
| -rw-r--r-- | gnu/usr.bin/cvs/BUGS | 248 |
1 files changed, 0 insertions, 248 deletions
diff --git a/gnu/usr.bin/cvs/BUGS b/gnu/usr.bin/cvs/BUGS deleted file mode 100644 index 3ad13a82828d..000000000000 --- a/gnu/usr.bin/cvs/BUGS +++ /dev/null @@ -1,248 +0,0 @@ -* `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. |