1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
See the README file for information on how to report bugs (and what
will happen to your bug reports if you do).
The following is a list of some of the known bugs. It may or may not
be comprehensive. We would dearly love for people to volunteer to
help us keep it up to date (for starters, if you notice any
inaccuracies, please let bug-cvs know as described in README). There
are some other reported bugs in MINOR-BUGS; the difference, at least
in theory, is that those bugs are less serious.
* For platform-specific information (in some cases including known
bugs), see README.VMS, windows-NT/README, or os2/README. There is no
similar file for the unix-like operating systems (not yet, at least).
This file also might contain some platform-specific bugs.
* The "&" feature of the modules file does not work correctly with
client/server CVS. The documented behavior (which is implemented by
non-client/server CVS) is the correct one.
* The -m option to "cvs add" does not work with client/server CVS.
CVS will accept the option, but it won't actually set the
file's description.
* cvs update walks into a user's work directory if there's a directory
of the same name in the repository even if the user's directory
doesn't yet have a CVS admin sub-directory. This can greatly confuse
users who try to add the same directory at nearly the same time.
* 'cvs admin' dumped core when files were missing from working directory
(and from the repository)?
* `cvs checkout -d nested/dir/path <module>' just doesn't work. The
simpler version -- `cvs checkout -d single-dir <module>' works,
however.
* 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: 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.
* Defining RELATIVE_REPOS is said to not work with client/server CVS.
* 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: 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: 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.
|
