[cvsnt] Re: Problems to access current (CVSNT_2_0_x) source

[Tony Hoyle]

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