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

[Markus Schiltknecht]

Hi,

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.

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

Yeah, sorry due to my misunderstanding, I've interpreted the whole graph 
wrongly.

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

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.

Then we only need to find merge semantics for suturing.

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

Correct, my misunderstanding.

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

Agreed.  Two or more devs...


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) and it 
has to conflict with 'drop' (i.e. introducing yet another non-content 
conflict).

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

Agreed. A good point for not approximating suturing by dropping.

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

Yeah, the 'symmetric' requirement for suturing.

However, I don't think of it as a bad thing, I rather take it as *the* 
challenge for monotone to deal with all kinds of operations users might 
want to do in parallel. Including parallel conflict resolution. :-)

Regards

Markus