Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)

[Markus Wanner]

Stephen,

On 06/05/2012 03:47 PM, Stephen Leake wrote:
> Actually, it's not a duplicate name conflict, it's a special case of
> drop/modified; the same as the existing test that's currently failing in
> nvm.issue-209:

Sure? In that case, I don't understand your approach. A drop/modified
conflict between two different node-ids should be impossible. And I'd
expect Q to introduce a new node id, given your description.

> Right. It's similar to another use case I have, with a vendor branch and
> a local branch. If the user adds a feature (in a new file) on the local
> branch, which the vendor then adopts, that's a duplicate name conflict.
> But resolving it once the wrong way leads to confusion:
> 
> V   L
> |   |
> V1  L1  new local feature, vendor bug fixes
> | \ |
> |   L2
> V2  |  vendor adopts local feature
> | \ |
> |   L3 duplicate name conflict; local drops vendor file (oops)
> V3  |  vendor bug fixes
> | \ |
> |   L4 duplicate name conflict again; this time, drop local file
> V4  |
>   \ |
>     L5 no conflicts
> 
> I was thinking this would lead to a dropped/modified conflict, but I
> guess it won't. But the confusion about nodes and names is similar.

I don't see the similarity, because it's not about a drop/modify conflict.

Moreover, in L4, you currently won't get no conflict, and correctly so.
The user has expressed that he wanted to delete the vendor's variant of
the file and instead use its own. That may well be exactly what she
wanted in the first place.

>> The immediate merge with the user explicitly dropping one file is what
>> he then can do to work around the short-comings of this approach, yes.
>> In that case, you've brought two conflicts to the users attention,
>> instead of none, as monotone currently would.
> 
> I'm inferring that you agree that's a good thing.

I fear I'm not, sorry. I think it's obfuscating things, instead of a
clearer failure mode (die-die-die, which is equally wrong, but at least
simple and clear).

> That's true. I agree that general support for suture would help here; I
> just think it's not worth the effort of doing that, since this should
> not happen in a well-managed project, or at least be very rare.

IMO die-die-die works better for "well-managed" projects. The policy is
simple: never delete something you might want to revert someday.

>>>> In case of M1 and M2 being sequential edits, the user would have to
>>>> "undelete" the same file several times, consider this:
>>>>
>>>>     A
>>>>    / \
>>>>   M1  D
>>>>   | \ |
>>>>   M2  P
>>>>    \ /
>>>>     Q
>>>>
>>>> If the user chooses to keep the file in both, P and Q, he'd end up with
>>>> two 'foo' files.
>>>
>>> merge to P is the only undelete; merge to Q has a duplicate name conflict.
>>
>> Yeah, same issue: modify/delete conflict resolved by keeping (AKA
>> asymmetrically copying) the file turns into a name conflict.
> 
> As above, this is not a duplicate name conflict, but a special case of
> drop/modififed. I will implement this test case to make sure I'm not
> still missing something.

AFAIUI turning this into a drop/modified conflict would require the
newly introduced node-id in P to somehow be related to the old node-id
of the file in A (and later M1, M2).

Arguably, from a users perspective, it shouldn't be a drop/modify
conflict, either. She already expressed her wish to keep the file in P.
Why should she do that again for Q?

> I wrote those two files to get clear what was needed to implement split
> and suture; I think they should be the starting point of any new effort.
> Although trying to read it again now is giving me a headache; it could
> be improved :). As usual with such things, it makes more sense when you
> are actively working on it.

Thanks for these pointers, I'll take a look.

Regards

Markus Wanner