monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] merge algorithm question


From: Nathaniel Smith
Subject: Re: [Monotone-devel] merge algorithm question
Date: Wed, 14 Dec 2005 02:53:17 -0800
User-agent: Mutt/1.5.9i

On Wed, Dec 14, 2005 at 11:44:33AM +0100, Markus Schiltknecht wrote:
> What's happening with the 'merge in working directory' feature? With
> that it would be easier to circumvent the problem.
> (Manually merge two revisions and then commit as having two ancestors).

Nothing has happened with it yet, per se.  I very much had it in mind
when writing the roster merge code.  The way the old merge code was
written, it assumed that every conflict would be resolved as soon as
it was found; if you didn't resolve a conflict immediately, it had no
way to continue the merge and find more conflicts.  This made
merge-via-working-directory quite hard to implement.

The new code outputs a declarative structure describing all the
conflicts, plus a partially merged tree, and expects its caller to
take this and fix up the tree using whatever conflict resolution
methods it has around.  For the first pass, we just have some code
that emulates the old style -- it just iterates over the conflicts it
founds, and prompts the user to resolve each one.

But it would be straightforward to instead implement the system
described at:
   http://venge.net/monotone/wiki/MergeViaWorkingDir
where we basically insert "fix up" the tree by inserting conflict
markers and so forth, and then write that out to the working copy.

For now the focus is on just getting rosters merged into mainline so
we can start using them internally and shake out the bugs, but once
rosters land I very much hope someone takes this on...

-- Nathaniel

-- 
  /* Tell the world that we're going to be the grim
   * reaper of innocent orphaned children.
   */
-- Linux kernel 2.4.5, main.c




reply via email to

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