bug-cvs
[Top][All Lists]
Advanced

[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
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]