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

[Markus Schiltknecht]

Hi,

Stephen Leake wrote:
> This is the same duplicate name conflict that was noticed when merging
> a and b to get d. So merging g and h fails with a duplicate name
> conflict, and 'merge --resolve_conflicts' lets the user resolve it,
> by another suture.

Huh? Out of c, d and e, which we are merging, only d contains a suture 
(i.e. sort of renaming). d and e are edits of the file. So there's 
certainly no duplicate naming conflict - that was solved by d. The 
question here is how to merge things later on.

> > >   ii) Pick one side and drop that side.  This still requires a
> > > "merge through suture" function, but that function can be more like
> > > pluck' in that you just move the patch from the dead node-id and
> > > re-apply to the live node-id.  Eventually all instances of the dead
> > > node-id would disappear.
> > Huh? I think that makes no real difference. Whether you 'reuse' one of
> > the node ids and special case merges from the other one or just
> > special case everything... you still have to solve the above problem
> > somehow (maybe with some sort of pluck). And the required amount of
> > code is probably the same.
>
> The current recommended resolution (in monotone.info) for duplicate
> name conflicts where there should be only one file is to drop one
> side.

Yeah, that's because we don't have suturing, yet. However, with that, we 
would certainly recommend renaming or suturing. (As you've pointed out 
when saying that dropping is a bad approximation for suturing).

> If we use that approach in this example, we get:
>
>        o
>       / \
>      a   b
>     / \ / \
>    c   d   e
>     \ / \ /
>      g   h
>       \ /
>        f
> o is our original revision.
> In a and b, two people independently introduced new files with the
> same name and purpose.
> In d, the file in a is dropped; content of the file in a and b is merged.
> In c and e, the files introduced in a and b were each independently edited.
> In g, the file disappears due to DieDieDie.
> In h, the files in d and e are merged correctly.
> In f, the file disappears due to DieDieDie.

Well, that doesn't include suturing, so what's the point here?

> I think this is a realistic use case; in c and e Abe and Beth are
> improving checkout.sh, while in d some supervisor has noticed the
> duplicated work and sutures them. Then g, h, and f are just Abe and
> Beth catching up.

Uh.. to avoid confusion, I wouldn't call that suturing now. It's the 
approximation using a drop and merging contents into the other file.

Monotone cannot currently tell that approximation of suturing apart from 
 a real drop and any other kind of editing of the other file.

> So we do need to do something to record the suture so that DieDieDie
> doesn't kill the file later. As people have been saying; I'm just
> taking a while to catch up :).

The problem here is not only DieDieDie, but also history. If you drop 
one file, previous (in the DAG) edits to that file will never get merged 
back to the other file.

> However, I'm not saying we need to get rid of DieDieDie entirely; just
> override it when there is a suture in the history.

We certainly need to get rid of DieDieDie, but that's quite a different 
feature, IMO.

Suturing certainly shouldn't 'override' a drop. That would mean monotone 
preferring one user decision over another. See my mail answering Thomas 
Moschny.

> Assuming we do that by adding information somewhere, and adopt the
> definition "suture = drop two, add one", this example becomes:

Okay.

> o is our original revision.
> In a and b, two people independently introduced new files with the
> same name and purpose.
> In d, the files in a and b are dropped, a new merged file is added,
> and the suture is recorded to defeat later DieDieDie.
> In c and e, the files introduced in a and b were each independently edited.
> In g, the files in c and d are merged correctly.
> In h, the files in d and e are merged correctly.
> In f, the files in g and h are merged correctly.
>
> There is no need for 'pluck' that I can see.

Yes, I'd agree to that.

> But maybe I'm missing
> something; maybe the code for "c and d are merged correctly" ends up
> looking like the code for 'pluck'?

No, the user needs to merge together c and d.

> I need to read the code to see exactly to which type this extra info
> could be added. I've started adding the rename resolution to merge
> (not checked in yet); that will help me understand the code better.

Very cool! So you are a step ahead, in a way. I'd say you urgently need 
the suturing feature ;-)

Markus