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

[William Uther]

On 07/05/2008, at 5:37 AM, Patrick Georgi wrote:

> Am Tue, 6 May 2008 19:54:19 +0200
> schrieb Thomas Moschny <address@hidden>:
> > The problem is, that the all deleted files will have to stay in the
> > rosters forever. This is not so much a problem storage-wise, because
> Couldn't resurrection be done with a revision item like
>
> resurrect "original path"
> from [ancestor rev]
> as "new path"
> with "content hash"

Almost.  The issue is merging.  At the moment monotone keeps node-ids  
for files.  These are unique to the file and are used for content  
merging.  The name and location of the file are irrelevant.  (In fact,  
the name and location for each node-id are treated as more bits of  
information that need to be merged.)

In your example above, are you creating a new node-id for the  
resurrected file, or not?

If you are, then you make the merge harder because you now have a  
bunch of node-ids referring to the same file and need to keep track of  
that somehow (maybe you could suture them together? :).

If you are re-using the old node-id, then you'll suddenly have  
revisions where the node-id doesn't exist, but exist again in children.

Imagine you're merging two revisions.  In one revision the node id  
exists, and in the other it doesn't.  Should the node appear in the  
merged child revision?  In some cases it should and in some cases it  
shouldn't.

A good idea would be to keep a boolean around with a 'liveness' bit in  
it and use monotones excellent scalar merge algorithm, mark-merge, to  
merge that bit.  Let the merge algorithm decide if the file is alive  
in the child.

But now you need to either a) keep this bit around for all previously  
used node-ids (a "graveyard"), or b) reconstruct the bit during the  
merge.

I don't actually think option b) is too hard.  I discussed bits of  
this before, e.g. here:

http://thread.gmane.org/gmane.comp.version-control.monotone.devel/12015/focus=12030

and I started implementing.  But then I ran out of time.

Be well,

Will        :-}