Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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