|
From: | Matthew Nicholson |
Subject: | Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: | Tue, 06 May 2008 22:21:21 -0500 |
User-agent: | Mozilla-Thunderbird 2.0.0.12 (X11/20080420) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |