Mercurial and Agile

[Matt Mackall]

On Wed, 2009-07-01 at 17:21 -0600, Bret Naylor wrote:
> Hi All,
> 
> I am a new user of mercurial.  I have searched all of the internet and
> have not had much luck in finding an answer to my question.  
> 
> Short Question:  Why is it so hard to cherry pick individual
> changesets and only move those across repositories?

Part of the problem is cherrypicking is not operationally well-defined.
It seems to be defined as "apply a patch, but without all the fiddly
bits".

There are basically two fundamental operators in our world: diff and
patch. There's a third operation called merge, which is actually built
from the first two. And there's a fourth (backout) which is a
combination of patch and merge. And there's a fifth (rebase) which is
basically a series of merges.

We can define a fairly complex "cherrypick" operator like this:

a-o-p-s-o-o   s is the change we want to pick, p is its parent
 \
  o-o-d       d is where we want it to end up

First check out p:

 hg up -C p

Then get change s in our working directory, without changing our parent:

 hg revert -a -r s

Now do a 'reverse merge' (needs 1.3) to the ancestor:

 hg up a   # linearly transplant change s to a -> s'

Now do a 'forward merge' to d:

 hg up d   # transplant s' to d -> s''


Ok, so that gets us a nice three-way merge, and if we're lucky, does so
without any user intervention. If we're unlucky, we might be launched
into the resolve process not once but twice. The fiddly bits turn out to
be hard to avoid.

In the 'lucky' case an 'hg export | hg import' would have done the job
just as well. And might even succeed in the unlucky case as well. The
big difference is you have to deal with .rej files rather than 3-way
merge conflicts.

-- 
http://selenic.com : development and support for Mercurial and Linux