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.