cvs 1.11.2 relative path bugs

[Chris Bohn]

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