[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 11:53:58 +1100 |
On 16/11/2007, at 9:48 AM, William Uther wrote:
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.
Yeah - I've given this a little more thought. It looks like there are
some issues here, but nothing major. It isn't so much to do with
conflicts between the paths of ghosts and non-ghosts - that can be
handled as I suggested above. However, textual conflicts between
different histories of the same ghosted node that don't get discovered
until the node is resurrected could be interesting.
Make a file a = "some text" in an original branch "o".
make two branches "x", and "y" of "o".
In each of "x" and "y", make a textual change to the file a, such that
the changes will conflict when merged.
In each of "x", "y", and "o", delete the file "a".
In "o", undelete "a".
Merge "x" and "y" (I'll label the merged branch "z"). Note that there
should be no conflicts at this point (because deleted nodes should
never conflict. The existence mark would be an accidental clean
merge. The text would never even be looked at.).
Merge "z" and "o".
In that final merge, you should get a conflict on the existence of the
file - the undelete in the branch "o" has never seen the deletes in
the "x" and "y" branches. More than that though, it is at this stage
that the content conflict between the "x" and "y" branches is
discovered.
Needs some thought.
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