On 1/8/06, Alexey Yudichev <ayud@newmail.ru> wrote:
> I am sorry I still don't understand the difference. Assume a file was renamed
> in the branch and modified in the trunk. During merge the old file
> name will be deleted locally and scheduled for deletion in repository
> (ignoring changes made in the trunk) and its copy will be added under
> a new name. This copy will not contain changes made in trunk. So
> again, the changes are silently lost.
I totally agree with you that in the rename case that is the RIGHT
thing to do, the problem is that we can't tell the difference between
the rename case and an actual delete. If you really meant to delete
the file, then the subsequent modifications to it on the trunk are
pointless, and a conflict will just slow things down. Why should we
break that functionality when what we really want is to add the
underlying framework to allow us to actually detect the case where we
really need a conflict (or actually, where we want to be able to merge
the trunk changes into the renamed file or something). If we have
actual renames that gives us the ability to have the correct behavior
here, without that we can only fix this in half-assed ways that aren't
satisfying in all cases.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 8 18:24:03 2006