1
0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-16 10:20:30 +00:00
freebsd/gnu/usr.bin/cvs/MINOR-BUGS
Peter Wemm b05543098c Import CVS-1.6.3-951211.. Basically, this is the cvs-1.6.2 release
plus a couple of minor changes..  

Some highlights of the new stuff that was not in the old version:
 - remote access support.. full checkout/commit/log/etc..
 - much improved dead file support..
 - speed improvements
 - better $CVSROOT handling
 - $Name$ support
 - support for a "cvsadmin" group to cut down rampant use of "cvs admin -o"
 - safer setuid/setgid support
 - many bugs fixed.. :-)
 - probably some new ones.. :-(
 - more that I cannot remember offhand..
1995-12-10 22:31:43 +00:00

61 lines
2.2 KiB
Plaintext

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?