[cvsnt] checkout renamed files fails in RC9

[Arthur Barrett]

Gabriel,

> 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
bug.

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 
> "test-rename":

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.

Regards,


Arthur