Re: Merge bug causes changesets to be applied although this should not be the case

--
Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise
<http://www.wandisco.com/training/webinars>
----- Original Message -----
> From: Stefan Sperling <stsp_at_elego.de>
> To: Christoph Schulz <develop_at_kristov.de>
> Cc: dev_at_subversion.apache.org
> Sent: Thursday, 11 April 2013, 19:42
> Subject: Re: Merge bug causes changesets to be applied although this should not be the case
> 
> On Thu, Apr 11, 2013 at 09:01:09PM +0200, Christoph Schulz wrote:
>>  However, if I delete a
>>  _directory_ in trunk and testing (the directories are also identical
>>  and have the same ancestor) and then merge this deletion from trunk
>>  to testing, a tree conflict is raised:
>> 
>>  !     C testing/a
>>        >   local delete, incoming delete upon merge
>> 
>>  According to your argument, this is no conflict at all, because
>>  there is only one way of resolution -- the non-existing directory
>>  (which is to be deleted again) remains non-existing. For whatever
>>  reason, it _is_ seen as a (tree) conflict. Why?
> 
> Delete vs. delete is not a real tree conflict. The problem here is that
> Subversion cannot tell apart the following cases right now because,
> internally, in the implementation, they all look the same:
> 
>   delete vs. delete
>   rename vs. delete
>   delete vs. rename
>   rename vs. rename
> 
> So we have to treat delete vs. delete as a tree conflict because it
> could be any of the other cases (which are real tree conflicts).
> 
> But this has nothing to do with the file content merge we're discussing.
Actually, there exists a closely analogous ambiguity with file content: moving a bunch of lines from one place to another within a file can be confused with deleting those lines.  If I move a function (in a source code file) further down in the file, while my colleague moves the same function further up in the file, then the typical 3-way text-merge tool will see each of these as a deleted hunk and an added hunk, and will silently combine the two instances of the same deletion, and will perform both instances of the addition, so we'll end up with two copies of the function that each of us thought we were simply moving.
- Julian