[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Mark merge for existence
From: |
William Uther |
Subject: |
Re: [Monotone-devel] Re: Mark merge for existence |
Date: |
Fri, 16 Nov 2007 09:48:53 +1100 |
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 :-}
Re: [Monotone-devel] Mark merge for existence, Markus Schiltknecht, 2007/11/15
Re: [Monotone-devel] Mark merge for existence, William Uther, 2007/11/15