RE: defining obstructions (was: Re: svn commit: r1687029 - /subversion/trunk/subversion/tests/cmdline/mergeinfo_tests.py)

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: woensdag 24 juni 2015 08:44
> To: Bert Huijben
> Cc: Julian Foad; dev_at_subversion.apache.org
> Subject: defining obstructions (was: Re: svn commit: r1687029 -
> /subversion/trunk/subversion/tests/cmdline/mergeinfo_tests.py)
>
> On Tue, Jun 23, 2015 at 11:59:25PM +0000, Bert Huijben wrote:
> > Update and merge report ‘obstructed; for different reasons… But are within
> itself pretty consistent, and the documentation of obstructed in svn_wc.h
> supports both implementations.
>
> Can you explain how the reasons for reporting an obstruction are different?
> I've tried finding the explanation in subversion/include/svn_wc.h but
> could not find any.

On Update/Merge things are easier:
We merge incoming changes compared to a common base in local modifications. (3 trees)

diff(original->right) into diff(original->working)
left=original

But on merge we merge the difference between left and right into a local tree that has modifications. (4 trees)
diff(left->right) into diff(pristine->working)

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.

>
> I believe we should only use 'obstruction' to refer to something that is
> unversioned from the point of view of the working copy we're operating in.
> Note that this includes sub-directories containing unrelated working copies
> which were checked out separately, and thus also externals.
>

But on merge this isn't the case. The most valuable information would be where you would want the merge to be applied.
* Was the node moved locally?
* Was the node moved remotely? (But the move not yet merged)

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:
* We only mark tree conflicts, but we offer no resolve features yet.

The only exception now (1.9+) is move conflicts during update/switch...
In 1.8 we started handling those, but left out many corner cases. For 1.9 I fixed all the corner cases that I could find during extensive testing (Including many cases that would break the working copy state in 1.8)

        Bert
Received on 2015-06-24 11:32:40 CEST