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

[Markus Schiltknecht]

Hi,

Stephen Leake wrote:
> No, the two choices are suturing vs renaming. They reflect different
> understandings of the purpose of the added files.

Aha, okay.

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

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

Okay, so that's a conflict which we cannot (and don't want to) solve 
automatically, yes.

> 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. Sure, makes sense.

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

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

Well, it's the users decision, so I don't care much ;-)

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

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

Maybe we can let suturing win over dropping (that is, dropping one of 
the origin node ids, assuming that suturing creates a new node id - 
which it probably has to, to be able to maintain symmetric properties).

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

Agreed, makes sense for suturing vs renaming.

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

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

Okay, very cool.


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.

Regards

Markus