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

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

> sorry, I still didn't get around reading your initial plan on how to
> handle non-content conflicts. 

We're all busy :).

> It's great you are taking care of this!

Thanks.

>> The use case is that a file with the same name is added on two
>> different heads (or branches), and then the heads are merged (or the
>> branches propagated).
>> There are two possible resolutions; the files should be "sutured"
>> into
>> 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.

>> However, that appears to be quite a bit of detailed work. At a
>> minimum, it requires preparing at least one more roster to allow
>> commiting the drop before proceeding with the merge. So perhaps
>> it would be better to implement file suturing now.
>
> Yes, absolutely.
>
>> I searched the mailing list archives for suturing. Nathaniel outlines
>> the basic objection to it here:
>> http://lists.gnu.org/archive/html/monotone-devel/2005-05/msg00326.html
>> The problem use case is:
>>        A   B
>>       / \ /|
>>      |   X |
>>      |  / \|
>>      | C   D
>>      |/
>>      E
>>     Suppose A has "add foo", B has "add foo", D is a simple merge,
>> so
>>     D contains a single sutured file name "foo". Suppose also that C
>>     has "rename foo bar", and E is a simple merge, so E has two files
>>     "foo" and "bar".
>> In pratice, what this means is one developer has decided to resolve
>> the conflict via renames (deciding the files should be separate),
>> while another developer has decided to suture the files (deciding they
>> should be the same). Clearly one of these approaches is simply wrong,
>> and should be reverted.
>
> That problem would easily disappear if you rename in all cases.

I don't follow. If I add a renames step to this use case, I get:

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

How does that help?

The "problem" is that two different developers chose to resolve the
conflict in different ways. There is no reason for monotone (or any
other tool) to support that. We may need to add something to support
reverting one side, if it does happen by accident; 'mtn disapprove E'
may not be enough.

> If you absolutely want to offer the developer a choice in such
> situations, it might be better to rename first, then drop. 

But we want to avoid 'drop', since that loses history. Instead, we
want to suture, preserving history.

> Have you considered what happens, if two developers both decide on
> merging the files, but a different node-id is choosen? As node ids
> are local only, I think you cannot prevent that easily (i.e. by
> choosing the lower node id - those might be different - you'd have
> to compare birth date of the files. And even then, it might be
> possible they were born on exactly the same date...).

Any time two developers try to resolve the conflict in parallel, there
will probably be problems. The only solution is to revert one of those
resolutions.

> So, suppose A has "rename some to foo", B has "rename thing to foo"
> (just to use another ncc).  

A use case for this is that 'some' and 'thing' are names for files
with the same content, but they didn't follow the naming convention;
'foo' does. So this is similar to 'foo' being added in two parallel
revisions.

> Dev 1 merges the files and decides to keep "foo" from rev A. Dev 2
> also decides to merge, but decides to keep "foo" from rev B.

If we are truly "merging" via suturing, nothing is dropped, and
everything is fine. If we are approximating suturing by dropping, then
this is an issue.

> If you then merge C and D, both node ids will disappear and the
> merged revision will lack file "foo". :-(

This is an excellent example of why we need suturing instead of
dropping. Alternately, an excellent example of why parallel resolution
of conflicts is a bad thing.

>> However, I don't see anything in the mailing list about how to actually
>> implement suturing.
>
> Well, AFAIK the plan is to add a liveliness attribute to the files.
> That's a simple boolean flag which gets merged with our normal merge
> algorithm.

Hmm. Resurrecting dead files is not needed here. I think we need a way to
record the fact that a single file node has two ancestor file nodes.

-- 
-- Stephe