monotone-devel
[Top][All Lists]
Advanced

[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         :-}





reply via email to

[Prev in Thread] Current Thread [Next in Thread]