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

Hi,

On 06/05/2012 02:02 AM, Stephen Leake wrote:
> 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'.

Sounds good, thanks.

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

Uh.. wait. I didn't proceed with merging P and Q. Those are separate
revisions which aren't necessarily merged directly. Consider a rename or
other modifications to the files involved before merging... The point is
that we now have two node-ids on the horizon, for something the users
considers to be the same file, but without mtn knowing. That's a problem
per se, IMO.

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.

Anything involving renames after P or Q before merging won't even show
the inconsistency to the user.

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

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

Well, here we obviously disagree. But I haven't tried implementing
sutures (or resurrection). Where do I find your work on sutures?

Regards

Markus