Re: [Monotone-devel] resolving name conflicts; file suturing vs drop

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

> Stephen Leake wrote:
>>>> one file, or the files should be renamed to different files.
>>>> Currently, "suturing" is not supported, so we approximate it by
>>>> dropping one file, and manually merging its content with the other
>>>> file.
>>>
>>> Hm.. isn't approximation by renaming simpler? That way, you'd just
>>> have to rename in any case and let the user solve the ncc later
>>> on.
>>
>> I don't see how renaming is an approximation to suturing. The point
>> of suturing is to start with two files and end with one. I can
>> rename either or both of the newly added files; I still end up with
>> two files.
>
> Ah, sorry, I misread and thought of resurrection only. "Suturing" is a
> pretty new term for me ;-)
>
> Of course, you are right then: suturing can be approximated by
> dropping one file, yes. However, given die die die, it's a pretty bad
> approximation.

Ok.

>> The "problem" is that two different developers chose to resolve the
>> conflict in different ways.
>
> Yes, namely between: merging the files into one or dropping one of the
> offending files.

No, the two choices are suturing vs renaming. They reflect different
understandings of the purpose of the added files.

Here are my two canonical examples:

Renaming: Beth and Abe each start working on thermostat models; Beth
on a Honeywell thermostat, Abe on a Westinghouse one. Due to poor
planning, they both name their files "thermostat.c". When they merge,
the get a duplicate name conflict. They realize the resolution is to
rename Abe's file "thermostat-westinghouse.c", and Beth's file
"thermostat-honewell.c".

Suturing: Beth and Abe each realize it would be useful to have a shell
script to checkout a working branch. So they both create a file named
"checkout.sh". When they merge, they realize the two files should be
sutured. 

This graph represents either case:

        A   B
       / \ /|
      |   X |
      |  / \|
      | C   D
      |/
      E

A is Abe's revision with his original file, B is Beth's. D is a
sutured resolution of the duplicate name conflict, E has a rename
resolution. monotone has no reason to prefer one over the other, but
they cannot both be allowed to survive.

But the developers do have a reason to prefer either D or E. 

If it's the thermostat case, E is correct; it contains
thermostat-westinghouse.c and thermostat-honewell.c. D contains a
mistakenly sutured thermostat.c

If it's the checkout case, D is correct; it contains the sutured
checkout.c. E contains mistakenly renamed checkout-abe.sh and
checkout-beth.sh.

In either case, the incorrect revision(s) should be disapproved.

There may be some use case where it's not as clear which resolution is
correct, but I doubt it.

I guess there is a use case for dropping one file; it was created by a
novice and is not worth suturing. So that's a third use case. I don't
think it's worth supporting in 'merge --resolve_conflicts'; the
novice's mentor should clean things up before merging :). 

More importantly, the content of a sutured file is the result of a
(manual or automatic) merge of the two original files. So in the
novice case, the mentor can do a manual merge and keep the
better-written version, but also keep the novice's history.

> Now, my point probably was, that we could rename first, to let the
> merge succeed. And then add a helper revision which either drops one
> of the files or sutures the two together. However the developers doing
> the merge decide, they would get the same merged revision first, with
> different helper revisions. Having three possible outcomes: dropped
> left, dropped right or sutured.

Yes, that is one possible resolution process. In the checkout.sh case,
it introduces a bogus renaming, which will make the history confusing.
So I think it's simpler to just suture or rename in one step.

I think the command 'merge --resolve_conflicts' will need create
helper revisions with renamings, drops, and/or other changes to allow
the final merge to succeed. But that should be transparent to the
users, except in history logs.

> So, whatever the 'suturing' operation looks like, it has to be
> symmetric (i.e. suturing 7 and 8 has to be the same as suturing 8 and
> 7) 

Yes.

> and it has to conflict with 'drop' (i.e. introducing yet another
> non-content conflict).

Good point.

I'll start by implementing the renaming resolution case, to flesh
things out more.

-- 
-- Stephe