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

[Thomas Moschny]

Markus Schiltknecht wrote:
> 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. 

Agreed, but in the example, this is not the case anyway. The only thing I said 
was: *If* we implemented suturing as drop,drop,add (all within D), and not 
cared about the relationships between the newly created file and its 
predecessors, then there were no conflicts at all while merging D and E.

*But*, I changed my mind, and now think that we must care about file identity 
relationships. What we really want, is this: Pretend we could go back and 
give both 'foo' nodes in A and B the very same node identity. The whole 
monotone merging machinery would work as expected.

However, we simply can't do that. We can't go back and treat two different 
file identities as a single one. Well, we can do it, locally, but only *as 
soon as we know about the users wish to do so*. And the user in turn cares to 
tell us only when ncc conflicts arise. And that's the point with Nathaniel's 
example: D knows about the problem, but E does not, so in E we have two 
nodes, and a delayed (=not yet resolved) content conflict popping up when we 
merge D and E.

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

Let me put it in other words: Killing DieDieDie and implementing suturing 
properly will both yield merges where we are confronted with a series with 
more than two content conflicts on the same file.

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

They do, see above. 

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

No, no. Height information is also a cache, but at the level of revisions, and 
totally unrelated here.

Rosters are caches carrying per-revision, per-node information (see my other 
post), but are currently accessible per-revision only. All I'm saying is that 
we should break this up and allow access to node-specific parts of a roster.

Regards,
Thomas

signature.asc
Description: This is a digitally signed message part.