Re: renaming under CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Sunday, February 24, 2002 at 20:59:30 (-0800), Noel Yap wrote: ]
>> Subject: Re: renaming under CVS
>>
>> Let me explain so even you can understand:  Developer
>> A should be able to modify a file while developer B
>> renames it.  The merge should go gracefully and
>> seemlessly regardless of who checked in first since
>> there is no conflict.  But this isn't true when using
>> CVS.

>In the original scenario both developers were working on different
>branches.

The treatment of renames during merges should work the same way
regardless of whether or not the two developers share a branch.
A 3-way merge is a 3-way merge, and the point here is that
directories should be treated in substantially the same way as
files, with regard to merging changes to their contents (i.e.
the mapping between version histories and the location of a
version in the directory trees).

>Developer-A can easily modify all the files on branch-A without any
>interference whatsoever while developer-B renames a file on branch-B.
>Since you won't be merging between branch-A and branch-B without first
>renaming the same file on branch branch-A there's no conflict.

The idea is to have CVS automatically merge Developer-A's change into
the proper place in the proper file on branch-B during an update.
It saves Developer-A from having to do the rename in the first place
(necessary if branch-A is a maintenance branch where renames are
discouraged), and it converts modify/remove conflicts into something
else (either an automatic merge or a diff3 conflict) that is arguably
easier to resolve.

Note that even if branch-A and branch-B are really the same branch,
the treatment is identical.

>If you actually try this with a test module and a couple of test
>directories, you'll find this isn't actually as big a problem as you
>seem to think it is, and it does not require serialisation.  You're
>right that the merge doesn't happen seamlessly, but that's the nature of
>working with a tool that only tracks changes in the contents of files.

>I've never had any trouble with renames when multiple working
>directories exist for multiple developers, not even if every other
>working directory but where the file is renamed contains un-committed
>changes to that same file.  It really is quite simple to handle, and it
>does not involve committing any changes, or even re-applying them
>manually to the new file.

You have admitted elsewhere in this thread  that you've only had to
rename one file in eight years, and that the effort was small considering
the coordination that was required among the limited number of developers
exposed to it.  It's no wonder your comments are so far off base, because
you have no practical experience.

You're the one who should be trying this with a (large) test module
and see how difficult it really is when large numbers of files are
renamed, even if the number of exposed developers is small.  Maybe
then you'll understand why so many of us want the tool to be extended
to track more than just the changes in contents of files.

>You really should test such things out before you make false claims.

You should take your own advice.

>--- End of forwarded message from address@hidden