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

[Justin Patrin]

On Tue, May 6, 2008 at 12:58 AM, Markus Schiltknecht <address@hidden> wrote:
> Hi,
>
>
>  William Uther wrote:
>
> > I can't see an easy way to implement this without a graveyard.  If you're
> > going to implement a graveyard, then I'd get rid of DieDieDie merge first.
> >
>
>  Hm.. I don't see what file resurrection has to do with suturing. Of course,
> resurrection would help the user to revert from erroneously sutured files.
> But that's the point of it.
>
>
>
> > You could then implement the 'drop one side' approximation to a suture,
> and
> > know that DieDieDie merge wont kill you.
> >
>
>  To be symmetric, suturing will have to drop both source files and create a
> new destination node. Only that way you can resurrect any of the two files
> later on, for example.
>
>  I'm thinking of suturing as an atomic "delete two, add one" operation.

Except, of course, that the history points to both the deleted nodes,
causing merging and such to work "properly", correct? It seems to be
that implementing this as 2 drops and 1 add could be problematic in
this kind of situation:

   B
|\ /|
| C |
D   E

A and B both have newly added files 'foo' with the same or different content.
C is a sutured merge of the two.
D has a content revision to 'foo' in A.
E has a content revision to 'foo' in B.

If 'foo' in A and B has the same content and D and E make the same
change this should all merge    cleanly to:

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

H which has the sutured file from C but the changes from D and E.

If 'foo' in A and B have the same content and D and E have changes in
different       parts of the file, the merge should happen automatically to
H with the sutured file having the changes in   both D and E.

If 'foo' in A and B have the same content and D and E have conflicting
changes then the merge will result in a content conflict which needs
to be handled by the user, finally ending up with the sutured file
with the changes. I suspect the same is true if A and B have different
content in 'foo' as well.

Repeat with instances of D and E having renames of the file.

And, of course, similar cases also apply for copy (mtn only allows
rename currently), which is a lot like a 'reverse suture'.

>
>
>
> > Once you have a graveyard, appending information to dead nodes, such as
> > "this node was merged into this other node" would make future merges
> easier.
> >
>
>  Hm.. maybe you need to outline your graveyard concept a little better. Last
> I've heard about file resurrection, we should simply add a boolean flag for
> alive or dead. That hardly carries any extra information, but could be
> merged the same as other attributes.
>
>  Regards
>
>  Markus
>
>
>
>
>
>  _______________________________________________
>  Monotone-devel mailing list
>  address@hidden
>  http://lists.nongnu.org/mailman/listinfo/monotone-devel
>



-- 
Justin Patrin