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

[Matthew Nicholson]

William Uther wrote:

> This third option would avoid the drops entirely.  It has the problem 
> that I don't know how to reverse it.  i.e. if you merge two node-ids 
> then you could never tease them apart again.  Hrm.  You could just 
> introduce a new node-id with the current contents, but you'd have lost 
> some of the details in the history.

Reversal involves making two new node id's each with the sutured node as 
a parent.  History is preserved and the files are split again.  This of 
course is roughly equivalent to the copy/split operation I have seen 
floating around.

> At the moment dropped node-ids are gone.  Introducing a graveyard means 
> keeping all node-ids around.  The standard thought for resurrection is 
> to keep them around with an 'isLive' boolean attached to them that can 
> be mark-merged.  But once you're keeping around all the node-ids, it 
> wouldn't be hard to keep around more information.  That extra 
> information could be the "replacement" node-id for node ids that were 
> dropped as part of a suture.  The extra information could be the 
> 'parent' node-id from a disjoint sets data structure.

This is very similar to what I was thinking when the "atomic drop two 
add one" idea was first presented.  This is basically a combination of 
your options i and iii, although with pure option 3 you don't need the 
graveyard.

--
Matthew Nicholson
matt-land.com