Re: Subversion merge creates bogus tree conflicts

David Moon wrote:

> Julian Foad wrote:
>>> Hmm, I wonder if the directory not existing on the target means this is actually
>>> a simple bug, not really some complicated problem with merging.  Why wasn't
>>> the parent directory of a file being added created automatically, as if svn
>>> merge took a --parent argument?  When would that be harmful?
>>
>> It's very complex -- in general (different merge scenarios) the delete
>> might have been a conscious user action committed in the target branch, and
>> might be a move away rather than a plain delete, since svn still lacks move
>> tracking.  We can't assume that just recreating the dir is the right thing,
>> although it should be offered as an option in the conflict resolver.
>
> I assumed, perhaps incorrectly, that svn knew the difference between something
> being deleted and something never having existed.  In other words, if the
> directory had existed and then been deleted or moved, the list of changes being
> merged would have included a delete.  But if the directory never existed before
> it would not be mentioned in the list of changes being merged.
>
> Just trying to be clear and unambiguous.

We're talking about the scenario where an incoming change is a file being added inside a directory which doesn't exist on the target.  The "delete" isn't an incoming change (a change that happened in the merge source), rather "delete" is how we are describing the apparent difference between the old side of the merge source (where there is an 'A') and the target (where there isn't).  "delete" is a misleading word for the UI to use in this case, for sure.  And as we're talking about a manual merge, we are merging branches with no common ancestry, so we can't really say in this case that "'A' never existed" nor that "'A' did exist and was deleted"; rather we have two separate lines of history and 'A' existed in one of them.

Of course the Subversion repository knows what existed where and when, but what's complex is figuring out how to interpret and present the relationships in terms of doing sensible things in all the combinations that a merge may encounter.

And I haven't even mentioned the fact that some users want strict conflict detection ("I have arranged my work flow such that I expect a smooth merge, so notify me if anything seems not to match up") while in other situations users want lenient conflict detection ("just create the result that includes the changes I most likely want and automatically omit duplicates, create missing dirs and so on; don't mark conflicts when there is an alternative").  In that regard I want to build in a switch to select either mode, but we don't have that yet.

- Julian
Received on 2013-01-15 20:13:32 CET