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

Markus Wanner <[email protected]> writes:

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

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:

346 merge((patch_a),_(drop_a,_add_a))            FAIL (line 29)

(see my other email on this)

It does have some aspects of a duplicate name conflict, and I have to
write some code to handle the special case.

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

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.

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

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

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.

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

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

It's in some nvm branch, but I don't remember the name. I think it was
not something obvious like "suture"; it was some other issue that grew
into that. 

There used to be a wiki page that described what people were working on;
that seems to be gone.

Ah; found it in ./wiki/Branches/nvm.automate_show_conflict.mdwn. The
branch is nvm.automate_show_conflict; it's currently suppressed. That
happened back when I was less aware of the importance of good branch
names :).

I've added the branch name nvm.split_suture (not suppressed) to that
branch head so we don't forget again.

That wiki page doesn't seem to be accessible from the web interface; I
found it by grepping in the mtn checkout of nvm.web.ikiwiki.

In that branch, there's a file ./multi-mark-merge.text that is the
original mtn branch/merge description. There's another pair
ss-existence-merge.text and ss-mark-merge.text that modify that to
describe split (one node becomes two) and suture (two nodes become one).
They start by describing what the user wants, then move on to how that
can be implemented efficiently. ss-existence-merge.text describes the
algorithm that replaces die-die-die. It's very complicated, due to the
requirement to consider _all_ previous sutures in a file's history on
each merge (any of the suture parents may have been independently
modified in the other side of the merge). 

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.

Of course, there may be another way to do it; I didn't put much effort
into finding an alternative before I gave up.

I don't remember if I got around to considering what happens when you try
to access the log of a file that had been sutured (which is when the
loss of history becomes apparent). But the data structures do record the
suture, so I think that could be done right.

The code implements some of the required support, but no where near all
of it. It got very complicated, and since my primary goal was to have
some way of resolving duplicate name conflicts, I gave that up and
implemented the current stuff. 

Hmm. There don't seem to be any notes on what's missing (there are eight
FIXME_SUTURE's). I hope running all the tests would make that clear. It's
also likely that there are cases described in the docs that are not yet
implemented in tests.

That work was based on monotone 0.4; it would probably be a lot of work
just to merge 1.0 into it!

-- 
-- Stephe