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

[Stephen Leake]

Markus Schiltknecht <address@hidden> writes:

> Stephen Leake wrote:
>
>> 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.
>
> Uh.. and C is a helper revision with the renaming, right?


Right.

>> 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.
>
> Uh.. yeah, so the atomic operation of 'suturing' should not only
> conflict with dropping a file, but also with renaming it. 

Right.

>> In either case, the incorrect revision(s) should be disapproved.
>
> Hm.. do we really need to disapprove the rev? Why don't we treat it
> like all other non-content conflicts and offer the user a clever
> merger, instead of relying on certification (which easily gets
> confusing and doesn't work, see OE story with suspend certs). OTOH,
> once we have policy branches...

In the typical case, the "mistaken" resolution won't be present, and
there won't be anything to disapprove. Disapproval is only needed to
recover when some developer makes a mistake.

Maybe there is a better way to recover.

>> 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 :). 
>
> I'm dubious about one point in your argumentation: you are always
> assuming having to merge only two revisions. But think about multiple
> merges, one after another, to merge multiple revisions from different
> people.
>
> A friend of Abe might have anticipated, that Abe runs into trouble
> with such an unspecific filename, and have committed a rename to
> "yet-another-termostat.c". While the friend of Beth simply drops
> Beth's work, because he thinks it's plain bulls**.
>
> Now, Abe and Beth don't listen too much to their friends, so they
> merge first. However, their mentors disagree on how the ncc needs to
> be resolved. Then Abe's and Beth's friends sync and try to merge their
> stuff...
>
> I think you get where I'm heading to...

Yes, it can get complicated. Let's get this simple case down first,
then get really devious :).

>> 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.
>
> Yeah, but that doesn't help all cases. In the above example, Beth's
> friend has deleted the file, while his mentor has sutured the same
> file with Abe's. Both resulting revisions look perfectly fine, but how
> is monotone going to merge them?

The mentor is going to have to sort it out, most likely by
disapproving something.

>> 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.
>
> That seems contradictory to what you just said. Why is that again?

Well, I'm not sure. I'll have to dig into the code.

> I've been thinking about suturing being pretty close to an atomic copy
> operation: both need to create a new node-id, and carry extra
> information about where it's contents came from.
>
> However, after a closer look at both operations, I think they have
> pretty different merge semantics: copy certainly doesn't conflict with
> dropping or renaming it's origin. It doesn't even do anything to it's
> origin. While a suturing op drops the two origin node ids, creating a
> third one.

I still have no idea how to actually implement this.

-- 
-- Stephe