263 lines
11 KiB
Plaintext
263 lines
11 KiB
Plaintext
|
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 <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 <info-cvs@prep.ai.mit.edu>
|
||
|
|
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: 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
|
||
|
|
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.
|