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.
Himmler, Peter wrote: > 1) With the future corrected rename support GUI clients like > tortoiseCVS doesn't have a chance to checkout a certain file revision > without the knowledge about past file renames and file renames could > only recognised in the enhanced cvs log output ;-) 2) IMHO a rename > support which is not transparent to the client will be a nightmare to > document (in the manual) They'll have to specify more information. Just a number is simply not enough. It's not a solvable problem otherwise. Tags help, as to dates. Just a file version isn't enough to find the file after a rename. Consider: file1a.c renamed to file1c.c file1b.c renamed to file1a.c file1c.c renamed to file1b.c You now have two files, file1a and file1b. co -r 1.1 file1a... which file1a? The one that's file1a now, or the file1a before we stated? There are legitimate reasons for either. Now expand that to directory renames - even a whole repository restructure. You start with a/b/c/file1.c Last week it was a/c/file1.c This week there's a/b/c/file1.c, but the directory c is actually what was b before, and c is a completely new directory, and file1.c is actually something completely different. It gets *really* hard to work out what's going on at the code level - I've come up with worse than that too. The 'safe' fallback is to use the tag/branch specified, or date, and in the absense of anything else whatever's in HEAD at the moment. That'll only work for a limited number of cases though - in your original example you clearly specified a branch revision but that number means nothing outside the file and you can't even *find* the file without knowing what branch you're talking about.. catch-22. Some syntax changes will be needed to handle this, and the frontends will have to change to accomodate as they start to support renames. Tony