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
