Re: Subversion merge creates bogus tree conflicts
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 15 Jan 2013 19:12:56 +0000 (GMT)
David Moon wrote:
> Julian Foad wrote:
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.
This is an archived mail posted to the Subversion Dev mailing list.