[cvsnt] checkout renamed files fails in RC9
arthur.barrett at march-hare.com
Tue Nov 4 10:19:25 GMT 2008
> Checking out specific revisions of a file that has been
> renamed fails in
> 2.5.04.3229 (RC9).
> Suppose I have a file old.txt:
> rev 1.1 = initial
> rev 1.2 = modified, renamed to new.txt
> rev 1.3 = current.
> Then (using the old name):
> cvs co -r 1.1 -p test-rename/old.txt : works
> cvs co -r 1.2 -p test-rename/old.txt : fails
> cvs co -r 1.3 -p test-rename/old.txt : works
> and (using the new name):
> cvs co -r 1.1 -p test-rename/new.txt : fails
> cvs co -r 1.2 -p test-rename/new.txt : works
> cvs co -r 1.3 -p test-rename/new.txt : fails
Yes - that looks correct. Version 1.2 has the name new.txt so it will
fail if you try and use old.txt.
> That is, I can retrieve ANY revision using the OLD name,
> EXCEPT the exact
> one corresponding to the rename operation, which must be
> retrieved using
> the NEW name.
> I could understand that I should use the new name for that
> revision AND
> any later revisions, but it's illogical to only require to
> use the new
> name for that exact revision and not the later ones.
> This behavior breaks the TortoiseCVS diff feature, and many history
> related commands.
OK - version 1.3 should also accept the new name. That appears to be a
If you are going to be doing a lot of renames then I suggest you use
EVSCM. For occasional renames then CVSNT works well - though what
you've shown here is probably fixable.
> Below there is a test script I've used to reproduce the
> issue. It assumes
> a valid CVSROOT set, and creates a new subdirectory named
Thanks - I'll get that added to the standard tests.
This will not be fixed in 2.5.04 stable - too late sorry - it's already
gone to the web site. But if possible I'll get it fixed within 30 days.
More information about the cvsnt