Re: Updated Issue 209 - support drop/modified conflict (monotone)

Markus Wanner <[email protected]> writes:

> Stephen,
>
> On 06/05/2012 03:47 PM, Stephen Leake wrote:
>>>
>>>     A        - file 'foo' exists
>>>   / | \
>>> M1 M2  D     - M1, M2: independent modifications to 'foo'
>>>  \ /\ /      - D: deletion of 'foo'
>>>   P  Q       - P, Q: merges, adding 'foo' under a new node-id
>>
>> 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.

Yes, but it's the same node that the drop-modify 'keep' resolution would
add. 

In the M2/D merge, the conflict is between the modified foo node in M2 and the
dropped foo node in D; the resolution created Q.

In the P/Q merge, the same conflict occurs; the original foo node in Q
is dropped. But the resolution would attempt to create the new foo node
in Q, so instead it reuses it.

>> 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.

I'll write up this test case as well; I now think it will be the same as
the above. This stuff is tricky!

>>> 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).

Since the current behavior is not what I want, I think it should be a
conflict, so the user can choose the current behavior (the 'drop'
resolution to the conflict), or something else (the 'keep' or 'user'
resolution to the conflict).

The reason I don't like the current behavior is that sometimes the drop
was a mistake, and it needs to be corrected; the easiest way to bring
that to the user's attention is via a merge conflict.

I'm assuming I'm not the only user with this issue.

>> 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.

Well, yes. But I'd call that "perfectly managed" :). And it requires
perfect foresight. People are not perfect, so we need some recovery.

>>>>> 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).

Yes, by the file name, which is why it looks like a duplicate name conflict.

It will be a problem if the file is renamed between P and the merge.

> 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 agree she should not have to, but it doesn't work that way because
monotone doesn't have sutures; it forgets about the previous conflict
resolution. This is the core of the complication with sutures; the
mark/merge structures have to store information about all previous
sutures, not just the most recent one.

This will be clearer when I get it implemented (not sutures, just the
special case of dropped/modified :).

-- 
-- Stephe