RE: defining obstructions (was: Re: svn commit: r1687029 - /subversion/trunk/subversion/tests/cmdline/mergeinfo_tests.py)
From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 24 Jun 2015 11:31:40 +0200
> -----Original Message-----
On Update/Merge things are easier:
diff(original->right) into diff(original->working)
But on merge we merge the difference between left and right into a local tree that has modifications. (4 trees)
In the first case we can call something that is not in original, but is in working a local addition. It will also *always* have status 'A'dd.
But in case of the 4 tree merge left and pristine are not necessarily the same thing... On catchup merges they mostly are, but in general they may be completely different.
If there is something in WORKING, while left->right describes an ADD, or a change to a different kind of node, then there is some kind of obstruction.
Whether there already exists something locally, or whatever that local thing is... is not really that relevant.
In the current update/switch processing we specialize those variants, as that is in most cases the most valuable information on how to resolve the conflict.
But on merge this isn't the case. The most valuable information would be where you would want the merge to be applied.
Calling this a local add, a local X, or a local obstruction doesn't really matter that much... . And I think that is why the merge code describes all these cases as local obstruction... as the node is *unrelated*.
In case of an update/switch the node can never be as unrelated as during a merge, as the nodes at least share the same path at a certain revision.
When resolving merge conflicts you would handle all these obstructions the same way... (Find proper target; reapply merge). While on update you would apply a different strategy.
But all of this comes back to the same problem over and over again:
The only exception now (1.9+) is move conflicts during update/switch...
This is an archived mail posted to the Subversion Dev mailing list.