More SVN->HG questions

[Greg Ward]

On Tue, Jul 7, 2009 at 1:05 PM, Jeff Squyres<jsquyres at cisco.com> wrote:
> 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).

Your svn workflow is backwards from how Mercurial wants you to work.
With Mercurial (and any other DVCS for that matter), you really want
to fix the bug on the oldest stable branch where it's worth fixing.
Then merge to branch n+1, n+2, ..., trunk.  (Err, default.)

In your case, it's "pull" rather than "merge", because you're using
separate repos rather than named branches within one repo.  But at a
conceptual level, it's all the same.

One way to think about is this: the graph of changesets in the repo
for release n+1 should be a superset of the graph for release n.  Of
course that's a pie-in-the-sky ideal that won't happen in real life,
but it never hurts to strive for an ideal.

One obvious place where this workflow breaks down is when you fix on
release n, n+1, ..., trunk and then realize that you need the fix on
release n-1 too.  The standard answer in this case is to transplant
the fix back to n-1, then dummy merge forward to make everything look
neat and tidy.

Greg