[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cvs 1.11.2 relative path bugs
From: |
Chris Bohn |
Subject: |
cvs 1.11.2 relative path bugs |
Date: |
Thu, 12 Dec 2002 15:16:11 -0500 |
I've actually found two related bugs. One has an easy work around, and one
seems to be a real problem. I'll start with the easy one first:
1. On a Windows machine (2000) using a cvs client (pserver) talking to a
UNIX (FreeBSD) repository, if you execute
cvs status ..\file.ext
you get
cvs server: protocol error: `../file.ext' contains more leading ..
cvs [server aborted]: than the 0 which Max-dotdot specified
It seems like the "\" is correctly translated to "/", but the Max-dotdot
isn't handled properly. On a UNIX machine (FreeBSD 4.6.2-RELEASE or SunOS
5.7), running the same command returns:
cvs server: nothing known about ..file.ext
===================================================================
File: no file ..vers.dat Status: Unknown
Working revision: No entry for ..file.ext
Repository revision: No revision control file
Here it seems the "\" is just lost completely. The easy fix for the
problem is to use "/" instead. Doing that, leads to problem number 2...
2 -- On a Windows (2000) or UNIX machine (FreeBSD 4.6.2-RELEASE or SunOS
5.7), if you use a relative path for going one level back and none forward,
it goes to a different CVS repository location to get file information
returning incorrect results. The example should clarify what this
means. Continuing from example 1, switching to use "/" instead results in:
> cvs status ../file.ext
===================================================================
File: file.ext Status: Needs Patch
Working revision: 1.1183
Repository revision:
1.964 /cvs/root/systems/installations/test/file.ext,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
This looks ok until I add that the project I was in was not
/cvs/root/systems/installations/test, it was
/cvs/root/systems/old/claims. Instead of doing a stat of ../file.ext, if I
just go to that directory and do a cvs stat file.ext, everything is just
fine. The repository and root files are all fine in all directories, which
is probably implied since the status is correct when not using a relative
path. Additionally, this is not a problem when using local repository
drives for CVSROOT. I've only compared it to using pserver, which
definitely has the problem. So on the UNIX side, if my CVSROOT is set to
/cvs/root, the problem doesn't exist. If on the same machine I switch to
use pserver, then the problem occurs. I've verified the problem occurs
using pserver in 1.11.2 (2000 test), 1.11.2+IPv6 (FreeBSD tests), 1.11
(FreeBSD tests), 1.11.1p1 (FreeBSD tests), and 1.11.2 (SunOS tests). I've
also determined that the problem does NOT occur in cvs 1.10 `Halibut' (2000
and FreeBSD tests).
The other interesting fact is that regardless of what project I have
checked out of cvs, when I use the relative path, the repository revision
always points to the same repository location (the referenced file is in
all of our projects in the same location). Other things to note:
a) doing a cvs log ../file.ext will show the log for the wrong location's file
b) using a relative path and adding more directories seems ok, e.g., cvs
stat ../otherdir/file2.ext seems to work just fine. It appears to just be
a problem going back one directory and none forward.
c) with (b) in mind, I tried cvs stat .././file.ext, but that didn't work
(it still gave the wrong results)
d) If I happen to reference a file that isn't in the
/cvs/root/systems/installations/test project, it indicates it is an invalid
entry:
cvs server: ../t.txt is no longer in the repository
===================================================================
File: t.txt Status: Entry Invalid
Working revision: 1.1
Repository revision: No revision control file
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
e) I have no idea why all of the cvs status commands point to this same
wrong location, e.g.
all point the repository to /cvs/root/systems/installations/test
even if I run the command from directories that point to
/cvs/root/systems/installations/test_2
or
/cvs/root/systems/old/claims
f) As expected, renaming /cvs/root/systems/installations/test in the actual
repository does in fact cause failures on the cvs commands because the lock
file can't be made
I don't see any work around for this bug, so any help is appreciated. Most
users at my company are currently using cvs 1.10, but that has a few issues
that have since been fixed that we would like to roll out, but I think this
bug above is cause enough for us not to roll it out now.
thanks
Chris
cbohn@rrinc.com
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- cvs 1.11.2 relative path bugs,
Chris Bohn <=