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

[Thomas Moschny]

On Saturday 10 May 2008 Derek Scherger wrote:
> Thomas Moschny wrote:
> > *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.
>
> Initially I really liked this idea, even though it does seem a bit
> strange to go back and rewrite the old rosters, it does accomplish
> suturing. However, on the way home today, it occurred to me that
> actually doing this may not be the right thing because it doesn't record
> history as it happened but actually changes the history which we're
> trying to preserve.

Sure. That's why I said 'pretend we could go back...'. It was merely a 
gedankenexperiment that can help us find out what the merging rules will look 
like, not a suggestion to really rewrite history.

> I'm back to thinking the right thing to do is to drop *both* old nodes
> and create a new one representing the suture, and to do whatever else we
> need to so that the new node somehow refers to both of its sources.
> 
> Similarly, for splitting a file (i.e. un-suturing) I think we should
> drop the original single node id and create two new ones that both refer
> to their single source.
> 
> For an asymmetric copy it seems reasonable to keep the source node and
> add a single new node representing the copy.
>
> So, "all" we need is some way for a node to refer to 0, 1 or 2 source
> nodes (2 for a suture, 1 for an asymmetric copies and splits and 0 for
> simple additions).

Exactly. In another mail in this big thread I wrote that I think we should 
extent each nodes' birth records to contain 0-2 source nodes (specified in 
terms of paths in one of the parent revisions.)

> Then we need to work this through the merging machinery. 

Right, that's what we need to do now: Find out how to merge two nodes that 
have a somehow connected node identity. My guess is that there will be 
different rules for content, path and aliveness (besides the fact that we 
need to update aliveness merging rules themselves first).

Regards,
Thomas

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