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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
