[Monotone-devel] Re: RFC: mtn split

[Nathaniel Smith]

On Thu, Aug 24, 2006 at 10:06:48AM -0700, Justin Patrin wrote:
> If you really need to "split" a revision you can always make a
> checkout of the revision you want to split then revert all but 1 of
> the changes and check this in. Then repeat for all of the different
> things you want to split. Of course you'd need to merge these again.

No -- this approach will end in tears :-).  Much better to use
'pluck' (or equivalent, pluck is just a convenient interface for
some diff/patch type functionality) to re-apply the changes against
the _parent_ of the mega-commit.

The problem is in the word "revert" -- to simplify things, say we have
a commit with two separate fixes in it, called f1 and f2.  Following
your scheme we have a graph:

     A     (contains f1 and f2)
    / \
   B   C   (B has f1 but not f2; C has f2 but not f1)

If we now merge B and C, monotone will cleverly notice that two people
independently _reverted_ some functionality.  (We know that this isn't
actually what was intended, but notice that there's _nothing_ in the
graph to tell us that -- if two people _did_ independently revert
changes, this is _exactly_ the graph you would get.)  Now, obviously,
the right way to merge two reverts is to produce a new tree where
_both_ pieces of functionality have been reverted, which is exactly
what monotone will do.

Moral: the merger is smart, but it only speaks one language, and that
language is "what changed?".  If you add something, the merger will
attempt to propagate that addition forward; if you remove something,
the merger will attempt to propagate that removal forward. So make
sure you're not just recording the tree you want, but also the changes
you want.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco