Re: [Monotone-devel] Re: Mark merge for existence

[William Uther]

On 16/11/2007, at 8:17 AM, Graydon Hoare wrote:

> I would not worry, in general, about the persistence of ghosts or  
> trimming their marks from the roster.

Fir my first pass, that is exactly my approach.  This is tricky enough  
code as it is, and it isn't an area where you want to make mistakes.   
Of course all development here is on a branch, and will need careful  
code review before being merged anywhere.

> I don't think people will be killing and resurrecting buckets of  
> files.

I think njs had an example of someone who was killing lots of files  
(not resurrecting them though).  If you have persistent ghosts, then  
you pay the costs for resurrection even if you don't use the facility.

> Maybe make a super-duper-kill command that drops a node forever,  
> relegating it to die-die-die, irrespective of "existence" state. Use  
> the "existence" mark for an undoable-kill, and make that the default  
> for UI actions like "drop". You can work out a UI for reviving dead  
> ghosts sometime later :)

Interesting idea.

I think my first pass will be to just keep the ghosts around.  I think  
it would be as much work to implement this idea from there as it would  
be to implement my own.

> A point you have to be sure to address throughout the tool is that  
> you have to modify things that detect conflicting nodes by path,  
> since paths can only have a unique *live* occupant. Change it such  
> that eg. a/b/foo.txt and a/b/foo.txt only conflict if neither of  
> those foo.txt nodes is a ghost. And likewise, when we write out  
> files and directories, we need to skip the ghosts.

hrm.  I hadn't thought too much about this... I'm sort of thinking out  
loud here, but let's assume for the moment that we're NOT keeping  
ghosts, but dynamically re-generating the needed marks when we get a  
merge that has a live node on one side and a dead one on the other.

When you do that merge with the dynamically generated marks, all the  
normal conflict detection mechanisms come into play.  I haven't looked  
at it closely, but I was assuming that would be close to just  
working.  Looking at it now, it looks like the check for this sort of  
conflict is in the roster_merge.cc:assign_name() function and it  
should just work.

For merges where a node is a ghost on both sides of the merge, I would  
just ignore that node entirely.  There is no way you should get a  
conflict here.  The conflict comes when you try to resurrect the node  
into a bad location.

> It's a little weird that, given this change, mtn may occasionally  
> find itself merging content, filename and attribute state on ghosts,  
> but probably harmless. I bet it will never happen. You could even  
> warn the user when it does: someone thinks they're editing a living  
> file, but they're talking to a ghost!

As I said, I would not do any merging on a node that is ghost on both  
sides of the merge, so this will never happen.

> I'm curious to see how it turns out, though. Please test extensively  
> and make the absolute *most conservative* form of this change you  
> can. Fiddling the merge algorithm is ... probably the most  
> destabilizing thing you can do to this program.

Yes.  Believe me, I'm fully aware of this fact.  In fact, I wish I  
could convince someone else who knows this code better than I do to  
make the first change : keeping ghosts around for files.  I'll  
certainly want an in-depth review before this is merged.  (In fact,  
I'll probably ask for a review of the branch when ghosts are in, but  
we shouldn't merge at that stage.  Think of it more as checkpointed  
reviews.)

Be well,

Will        :-}