blob: 7b857193f86bec2ad4922854d755152a905a1719 (
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
|
Low-priority bugs go here. We don't have many yet -- everything is
high-priority at the moment. :-)
* From: Jeff Johnson <jbj@brewster.JBJ.ORG>
To: cyclic-cvs@cyclic.com
Subject: Named_Root assumes . on server
Date: Wed, 17 May 1995 11:04:53 -0400 (EDT)
Problem:
On server, Name_Root() attempts (aggressively) to set CVSADM_Root.
If ~/CVS/Root exists (wrto rsh login), then CVSADM_Root will be
initialized from that file. The sanity check between the root
repository and the invocation will fail if the two values are not
coincidentally the same.
Workaround:
There's a zillion ways to fix this bugture/featurelet. My current
workaround is to remove ~/CVS/Root on the server. I shall attempt
a better fix as soon as I can determine what appears politically
correct. IMHO, the CVS/Root stuff (and getenv("CVSROOT") also) is
a bit fragile and tedious in an rcmd() driven CCVS environment.
* (Jeff Johnson <jbj@jbj.org>)
I tried a "cvs status -v" and received the following:
? CVS
? programs/CVS
? tests/CVS
cvs server: Examining .
===================================================================
File: Install.dec Status: Up-to-date
...
I claim that CVS dirs should be ignored.
* I sometimes get this message:
Could not look up address for your host. Permission denied.
cvs [update aborted]: premature end of file from server
The client's response should be cleaned up.
* In the gb-grep module, update-ChangeLog (and therefore, I assume,
rcs2log) truncates file names --- I get entries for things called
ring/lenstring.h instead of lenstring/lenstring.h.
* On remote checkout, files don't have the right time/date stamps in
the CVS/Entries files. Doesn't look like the C/S protocol has any
way to send this information along (according to cvsclient.texi).
Perhaps we can spiff it up a bit by using the conflict field for the
stamp on the checkout/update command. Please note that this really
doesn't do very much for us even if we get it done.
* Does the function that lists the available modules in the repository
belong under the "checkout" function? Perhaps it is more logically
grouped with the "history" function or we should create a new "info"
function?
|
