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

[Markus Schiltknecht]

Hi,

Thomas Moschny wrote:
> >        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". 
> >     Now, I merge E and D.  What happens? 
>
> If D actually dropped both 'foo' nodes and created a new one 'foo' node with 
> merged content, merging D and E would be a clean merge: drop 'foo' from A and 
> drop 'bar' (being 'foo' from B), and add the new 'foo'. No conflict (with or 
> without DieDieDie, in that example).

Hm.. no, we cannot let drop merge cleanly with suturing. Because those 
represent different user requests about how to proceed with a file. 
(Where monotone should not have any preference).

Think of the following:

        A   B            // both add "foo"
       / \ /|
      /   X |
     /|  / \|
    / | C   D            // let D be the suturing of the "foo"s
   F  |/                 // and (C, E) resolve the ncc with a drop
      E                  //
                         // I only appended F, which is an edit
                         // of "foo"


Now, we have three heads. If droping doesn't conflict with suturing, 
survival of the edit in F would depend on the merge ordering:

 * if you merge E and F first, then D, the edit in F is lost.
 * if you merge F and D first, then E, the edit in F is preserved
   (though the content merge problem for suturing applies).

Being dependent on the order of merges is certainly a bad thing (tm).

(The other bad thing being, that monotone favors the suturing over the 
drop).

Same applies for having a 'rename' in F. Thus suturing (as used to 
resolve non-content conflicts) needs to conflict with dropping and renaming.

> *Unless*, of course, we (after killing DieDieDie) decide that changing a 
> file's content or changing it's name causes it's aliveness state being marked 
> for the respective revision (in the sense of *-merge)[1].

Hm.. yeah, sounds reasonable.

> In *that* case, 
> there would be aliveness conflicts (and probably also a chain of content 
> conflicts following) for old 'foo' and 'foo' aka 'bar' nodes, like Nathaniel 
> described.

Uh.. why does marking aliveness state influence the amount of content 
conflicts?

> But that probably shouldn't scare us anymore after we have learned 
> how to control resurrection and the content conflict chains arising there.

I've completely lost you here, sorry.

> The problem is, that the all deleted files will have to stay in the rosters 
> forever. This is not so much a problem storage-wise, because we only store 
> leave rosters in full, and deltas for old rosters. Nevertheless it may have a 
> serious impact on speed as we still (at least temporarily) construct a lot of 
> full rosters for old revisions during common operations, e.g. pull.

Yeah, I'm aware of that problem. However, I don't think suturing (nor 
copying) has much to do with file resurrection.

> That's why I am still thinking we need a new storage scheme that allows easily 
> access to relevant parts of a roster - as we already do for restricted log 
> and annotate, but in a cleaner fashion.

Hm.. you mean splitting the aliveness information from rosters, as we 
have split height information? Or what do you have in mind?

Regards

Markus