tags:

views:

186

answers:

2

I am considering a switch from SVN to Hg and currently have a typical SVN layout for project Foo:

Foo
  trunk
  branches
    1.0
    1.1

I can import this structure into Hg using the hg import command, creating a separate repository for the trunk and two branches (by using the --config convert.hg.clonebranches=1 import switch.)

Now, if a customer finds a bug in v1.0 of Foo, how can I apply this fix to the 1.1 and trunk repositories? They're separate copies of the old SVN branches so hg merge isn't going to work is it?

If I was starting a new project from scratch on Hg then I could use tags for the different releases and easily merge changes from one tag to another, but I don't have this luxury when importing from SVN ... or have I missed something?

A: 

I like hg transplant (transplant extension homepage) for this: this will take a commit and move it somewhere. The -s option will let you move it from one repo to another.

You could also specify a merge to happen, and single revisions, multiple revisions, or have it fire up an "interactive changeset selector" (whatever that means). (Although I haven't tried the merge option between repos... but I know that specifying a changeset works just great!)

RyanWilcox
hg transplant isn't a great choice because then you have the same change with two different hash ids. In this case he should be able to just pull/push between them and then merge.
Ry4an
+1  A: 

You should be able to use normal push/pull merge to get the changes back and forth. Convert is smart enough that the parts of 1.0 and 1.1 that are identical will be the same changesets. So make the change in 1.0 and you should be able to pull it into 1.1 and main and merge cleanly.

If you think you'll be going from 1.1 and main into 1.0, just hg update to a changeset that you know is in 1.0 before making the change, and you'll be able to cleanly pull and merge that in 1.0 too.

Ry4an