summaryrefslogtreecommitdiffstats
path: root/contrib/cvs/BUGS
blob: b53576d87444d1ae319e2eacd2fb8299ac2f94a6 (plain)
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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
See the Cederqvist manual (cvs.texinfo) 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 the Cederqvist
manual).  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.


* If your login name contains a space or various other characters
(particularly an issue on Windows), CVS will have trouble (it will
write invalid RCS files, probably).  The fix would be to have CVS
change such characters to underscores before writing them to the RCS
file.  Furthermore, the LOGNAME or USER environment variables usually
won't override the system login name, so this can be hard to work
around.


* If you specify the -w global option to client/server CVS, it only
overrides a CVSREAD environment variable set on the client, not a
CVSREAD variable which was set on the server (for example, in .bashrc
when the server was run via rsh).  The fix of course will be to
provide a "Option-read-write" request which sends -w, in addition to
"Global_option -r" which sends -r.


* Symbolic links to files will not work with or without LockDir.  In the
repository, you should avoid using symbolic links to files since this issue
can cause data loss.  Symlinks are only a problem when writing files.  If your
repository does not allow any write access, symlinks are not a problem.


* Symbolic links to directories will not work with LockDir.  In the
repository, you should avoid using symbolic links to directories if
you intend to use LockDir as the correct directory will NOT be locked
by CVS during write.  Directory symlinks are not recommended, but should work
as long as LockDir is not being used.  Symlinks are only a problem when
writing files.  If your repository does not allow any write access, symlinks
are never a problem, whether or not LockDir is in use.


* "make remotecheck" sometimes fails on test 187a3 with
    cvs server: in directory .:
    cvs [server aborted]: *PANIC* administration files missing
This does not happen every time.  (-kingdon, Nov 96, Red Hat linux 3.0.3).


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


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

* CVS does not always seem to be waiting to the next filesystem timestamp
quanta after commits.  So far this has only shown up in testing under the BSDI
OS.  The symptoms are that ocassionally CVS will not notice that modified files
are modified, though the file must be modified within a short time after the
commit, probably milliseconds or seconds, for this symptom to be noticed.  One
suspected cause is that one of the calls to sleep_past() is being called with
an incorrect value, though this does not explain why symptoms have only been
noticed under BSDI.

* Spaces in arguments to `cvs diff' are currently split on spaces and tabs
before being passed to diff.  This can often cause diff to abort since it can
no longer interpret its options string and if it can, coincidentally,
interpret its option string, then the problem may be output in unexpected
formats.

* `release' of a project subdir does not remove the `subdir' entry from
  `./CVS/Entries'.

* The Windows Microsoft Visual C++ project files are out of date, but the
  project can still be built under Windows using `nmake'.  See the INSTALL
  file for more.

* Status

                             /*-------.
                             | Stable |
                             `-------*/

                     /*-------------------------.
                     | Sane for full scale use. |
                     `-------------------------*/

OpenPOWER on IntegriCloud