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

[Markus Schiltknecht]

Hi,

Thomas Moschny wrote:
> There can, that's what suturing is about.

Not if suturing conflicts with renaming and dropping, which prevents 
such a merge with certainty. That's the point of my proposal and why I'm 
thinking it's simpler (to implement as well as for the end user). 
Because it avoids even fancier merges.

Or are you stating that suturing shouldn't conflict with renaming or 
dropping?

> It is the same thing happening in C, 
> where we are suturing 1 and 2 both wanting 'foo' into 1&2. Why shouldn't that 
> be possible again in F for 1 and 1&2 ?

Because E and C represent conflicting user wishes on how to solve the 
original ncc between A and B.

> >        E             C
> >        |             G: -  # rev G drops 3 (i.e. the sutured 1&2) here
> >        H: 4,foo,v    /
> >         \ 5,bar,y   /      # rev H saves nodes 1 and 2 by
> >          \         /       # copying
> >           \       /
> >           F: 4,foo,v       # a clean merge now. 1 and 2 are gone due
> >              5,bar,y       # to the suturing into 3, which got then got
> >                            # dropped in G.
>
>
> You are cheating here. We don't have well defined nor understood semantics for 
> copy yet.

Well, I'm proposing some semantics, and I'm just now trying to 
understand 'em ;-)

> And by simply exchanging 3 for 1&2, or 4 for 1 and 5 for 2, you are 
> pretty much hiding what we are (well, I am, at least) talking about: 
>
> Establishing connections between different node identities. 

I've stated at the beginning of my previous mail, when explaining the 
1&2 -> 3 merger: "Of course the extra information 'created from suturing 
1 and 2' still has to be maintained".

However, that has nothing to do with content merging, because we try to 
keep content merging separate from aliveness merging.

> That is, a new node needs to able record the fact somewhere that it wants to  
> inherit (or asymmetrically share) identity from (with) another node.

Sure. That information would need to be part of the changesets, for one, 
AFAICT.

> What I'm thinking of (implementation wise) is extending the birth record to be 
> able to contain a list of 'ancestor' nodes, in terms of node paths in the 
> respective parent revision. Note (a) that we don't have node_ids there, so 
> nodes must be referenced by name, and (b) that we certainly don't want to 
> allow nodes to be referenced in other revisions than in its direct parents. 
> Otherwise we would create a new graph that can not be embedded in our 
> revision graph, and my intuition says that would be a very bad thing (tm).
>
> This would allow suturing and asymmetric copying, but not resurrection in the 
> copy-sense, "hopping" over a whole part of the history. But that's fine 
> anyway, because you can always commit a child revision of an old revision 
> where the file in question was still alive and merge that with your current 
> head, and that's the Monotone way of doing it.

Uh.. okay, I'm not quite grokking that approach now. Let me think about 
it for a while, ja?

Regards

Markus