More SVN->HG questions

[Giorgos Keramidas]

On Tue, 7 Jul 2009 13:05:15 -0400, Jeff Squyres <jsquyres at cisco.com> wrote:
> Thanks for your continued patience with my questions of converting a
> goodly-sized project from SVN to Mercurial.  Today, we have some
> questions about typical workflow using Mercurial between a large set
> of physically disparate developers (all of whom are coming from a
> long, strong SVN background).
>
> 1. When we use the convert extension to convert SVN->HG, something
> like this:
>
>      hg convert --config convert.hg.clonebranches=true \
>          -A username-map.txt /path/to/svnroot
>
> We get a directory with a "default" clone and a separate clone for
> each SVN /branches directory.  So far so good.
>
> Our question is: how do you work with these repositories after the
> conversion?  Specifically, we are used to committing a change (or
> series of changes) to the SVN trunk and then svn merge'ing from the
> trunk to our release branch(es).  We were expecting to use a similar
> kind of workflow: pushing changes from the "default" Mercurial repo to
> our release Mercurial repo(s).
>
> Using a test set of "hg convert"ed clones, I made a trivial commit on
> the "default" HG repo and then tried to pull it over to the "v1.3"
> clone:
>
> -----
> cd ...../default
> echo new file > foo
> hg add foo
> hg ci foo -m "new file"
> hg log | head
>     # ---> see that it was r12345
> cd ../v1.3
> hg pull ../default -r 12345
> -----
>
> This ends up pulling a lot of changesets and making a new head in the
> v1.3 repo -- not quite what I intended.
>
> How do you push/pull single r numbers from "default" to "v1.3"?  Or is
> the assumption of using an SVN-like workflow here a mistake -- should
> we be doing something different?

You don't.

If you pull a revision it carries with it all its ancestors.  This is
usually not the intended effect.

The transplant and/or rebase extension may help you with this sort of
patch cherry-picking.