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

Markus Wanner <[email protected]> writes:

> Hi,
>
> On 06/03/2012 05:57 PM, Stephen Leake wrote:
>>> fixed in branch nvm.issue-209; dropped/modified conflicts are fully
>>> supported.
>> 
>> I think this needs some review before I merge it to main.
>
> I'm surprised issue 209 doesn't mention die-die-die merge. I consider
> this a work-around to that problem. 

Yes, it is. But I was more focussed on the immediate use case. I kept
seeing the warning about "changes will be lost" fly by, and thinking
"that should be handled by the conflict resolution process". So now it
is.

I moved the discussion of the 'dropped/modified' conflict to right after
the missing root conflict (which is where 'die-die-die' is introduced in
the manual), and it now mentions 'die-die-die'.

> As such, it doesn't help in the rare case of a "missing root
> conflict", for example. More importantly, it's troublesome in cases
> involving multiple edits conflicting with one delete. With "parallel"
> modifications:
>
>     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

P is just a normal merge, while Q re-adds foo. Now it is a duplicate
name conflict, with the resolution of keep one (with merged
contents), delete the other.

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

Nothing replaces good management and solid naming conventions in the
first place :).

But I don't see any show stoppers here, just complicated situations.

It might be worth writing up these cases in tests to prove that, but
then it's hard to tell when to stop.

I think the second one would be sufficient in the tests.

>> In particular, the resolution process allows keeping the modified file.
>> This is implemented as a drop and add, which is what the user would do.
>> But it is done during a merge, so merge can now create new nodes.
>
> That's why I'd argue that "fully supported" is an exaggeration, as the
> "resurrected" file is disconnected from its previous versions, as you
> pointed out yourself.

Ok. Perhaps you could review what it says in monotone.texi, and possibly
reword.

> Ways of re-connecting it have been discussed before, but yeah, it's been
> awhile since the last die-die-die discussion...

Right; I started trying to do that in the 'file sutures stuff'. Way too
hard, for very little gain :).

Thanks for your input.

-- 
-- Stephe