While pushing changes back to Subversion is not officially supported yet, interoperating with it is possible with third-party tools or existing extensions. This page will detail the options and discuss their pros and cons.

Working with Subversion Repositories

For the following recipes, let's have a repository at svn://repo.org/subversion with a wanted module trunk.

1. With hgsubversion

HgSubversion is a third-party tool dedicated to convenient Subversion interoperability. Sources can be found at http://www.bitbucket.org/durin42/hgsubversion/.

To install it, you currently need to follow the steps layed out in this blog post by Ben Collins-Sussman: http://blog.red-bean.com/sussman/?p=116

Let's say you want to contribute to CPython. You first svnclone the repository.

$ hg clone svn+http://svn.python.org/projects/python python-hg

This way you get a folder named "python-hg" containing both a hg repo with each changeset mirroring an SVN revision.

When you want to produce a patch to the maintainers, it's simple:

$ hg di -b -r last_svn_revision:your_tip > mybugfix.patch

When you want to push the changes directly into svn, you first pull the latest changes from svn, then rebase your changes to the svn HEAD and push them back.

$ hg pull --svn # pull the changes from svn
$ hg up your_head # update the repo to the head of the changes you want to push to svn
$ hg rebase --svn # rebase your_head onto svn
$ hg push --svn

You can also first pull from svn and then generate a patch. This works just like pushing back, with the exception that you create the patch instead of pushing.

$ hg pull --svn
$ hg up your_head
$ hg rebase --svn
$ hg di -b -r last_svn_revision:tip > mybugfix.patch

Naturally you can use any of the various possible workflows to get the changes into the Mercurial repository you created with hgsubversion, including seperate feature or bugfix clones, but remember that you rebase the hgsubversion repository.

1.1. Pros

1.2. Cons

2. With MQ only

If we don't really care about existing history, and only want to hack an existing Subversion codebase with Mercurial and push changes back, we can start with an svn checkout and track it into Mercurial.

$ svn co svn://repo.org/subversion/trunk trunk
A    trunk/a
Checked out revision 1.
$ cd trunk
$ hg init
$ cat > .hgignore <<EOF
> \.svn/
> \.hgignore$
> EOF
$ hg st
? a
$ hg ci -Am "Initializing from subversion checkout"
adding a

Now we hack the sources. The trick is not to commit in Mercurial but to store all the changes as MQ patches.

$ echo b >> a
$ hg st
M a
$ hg qnew -f changea

If you want to have versioning on your patches, do:

$ hg qinit -c

Use MQ in the normal way, doing qrefresh (and qcommit if using versioning).

Once we are ready to push the patches, first resync with svn:

$ hg qpop -a
$ svn up
U    a
A    b
Updated to revision 3.
$ hg st
M a
? b
$ hg addre -s 75
adding b
$ hg ci -m upstream

Then apply the patch queue again.

$ hg qpush -a
applying changea
patching file a
Hunk #1 FAILED at 0
1 out of 1 hunk FAILED -- saving rejects to file a.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
Errors during apply, please fix and refresh changea

Oups, our changes do not apply any longer, we have to rebase:

$ hg up -C .^
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg qpush -a
applying changea
Now at: changea
$ hg qsave -c -e
copy .hg/patches to .hg/patches.1
$ hg heads
changeset:   4:ace2da3ad857
tag:         tip
user:        Patrick Mezard <pmezard@gmail.com>
date:        Sun Feb 17 15:39:11 2008 +0100
summary:     hg patches saved state

changeset:   2:6e35211ce252
user:        Patrick Mezard <pmezard@gmail.com>
date:        Sun Feb 17 15:38:11 2008 +0100
summary:     upstream

$ hg up -C 2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg qpush -am
merging with queue at: .hg/patches.1
applying changea
patching file a
Hunk #1 FAILED at 0
1 out of 1 hunk FAILED -- saving rejects to file a.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
patch didn't work out, merging changea
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
merging a
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
Now at: changea

In most case, you won't have to do that, the patch queue will apply cleanly. Now, we can apply one patch after another and push them into Subversion.

$ hg qpop -a
Patch queue now empty
$ hg qpush
applying changea
Now at: changea
$ svn st
?      .hgignore
?      .hg
M      a
$ svn ci -m "change a"
Sending        a
Transmitting file data .
Committed revision 5.
$ hg qdel -r qbase:qtip

At this point, our changes are in Subversion and in our local Mercurial mirror as real revisions. Large chunks of this process can be automated.

2.1. Pros

2.2. Cons

3. With Convert extension

First use convert extension to create a local reference mirror:

$ hg --config convert.hg.tagsbranch=0 convert svn://repo.org/subversion/trunk trunk-mirror
initializing destination trunk-mirror repository
scanning source...
sorting...
converting...
4 Repository initialization
3 append c to a
2 add b
1 change a
0 change a

Mercurial versions from 1.0 support shallow conversions like:

$ hg --config convert.svn.startrev=3 --config convert.hg.tagsbranch=0 convert svn://repo.org/subversion/trunk trunk-mirror
initializing destination trunk-mirror repository
scanning source...
sorting...
converting...
2 add b
1 change a
0 change a

Prepare the working copy. Instead of cloning the mirror, we checkout a working copy, make it a Mercurial repository, pull from the mirror and synchronize both. This way we end with an hybrid Subversion and Mercurial working copy.

$ svn co svn://repo.org/subversion/trunk trunk
A    trunk/a
A    trunk/b
Checked out revision 5.
$ cd trunk
$ hg init
$ cat > .hgignore <<EOF
> \.svn/
> \.hgignore$
> EOF
$ hg pull ../trunk-mirror
pulling from ../trunk-mirror
requesting all changes
adding changesets
adding manifests
adding file changes
added 5 changesets with 5 changes to 2 files
(run 'hg update' to get a working copy)
$ hg up -C
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg st
$ svn st
?      .hgignore
?      .hg

We hack it and end with an collection of patches in MQ. The situation is very similar to the one in "With MQ only" section. The difference is we do not change the patches into Mercurial revisions, we push them and get rid of them when done. Synchronize with Subversion first:

$ hg qpop -a
$ cd ..
$ hg --config convert.hg.tagsbranch=0 convert svn://repo.org/subversion/trunk trunk-mirror
scanning source...
sorting...
converting...
0 add c
$ cd trunk
$ svn up
A    c
Updated to revision 6.
$ hg pull -u ../trunk-mirror
pulling from ../trunk-mirror
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Then apply the patches:

$ hg qpush
applying changea
Now at: changea
$ svn st
?      .hgignore
?      .hg
M      a
$ svn ci -m "change a"
Sending        a
Transmitting file data .
Committed revision 7.
$ hg qpop
Patch queue now empty
$ hg qdel changea

Synchronize with Subversion again:

$ cd ..
$ hg --config convert.hg.tagsbranch=0 convert svn://repo.org/subversion/trunk trunk-mirror
scanning source...
sorting...
converting...
0 change a
$ cd trunk
$ svn up
At revision 7.
$ hg pull -u ../trunk-mirror
pulling from ../trunk-mirror
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[16:14:55][pmezard:~/dev/mercurial/svn/trunk]$ hg tip
changeset:   6:2fba38614917
tag:         tip
user:        pmezard
date:        Sun Feb 17 15:13:55 2008 +0000
summary:     change a

Again, large parts of this process can be scripted.

3.1. Pros

3.2. Cons

4. With hgsvn

hgsvn is not an extension, but bundle of three scripts for Subversion interoperability. It can be found at http://pypi.python.org/pypi/hgsvn/.

Let's say you want to contribute to CPython. You first import a recent chunk of the CPython history (starting from rev 60800 - so that it doesn't take too much time):

$ hgimportsvn -r 60800 http://svn.python.org/projects/python/trunk CPython
$ cd CPython
$ hgpullsvn

You are now in a folder named "CPython" containing both an hg repo (with each changeset mirroring an SVN revision) and an SVN checkout. It has an unique named branch "trunk".

You may start hacking immediately using "hg" commands to commit changes to your local working copy (you may use MQ for convenience). hgpullsvn helps to pull changes from remote SVN repository to keep your copy in sync.

When you're ready to submit your changes, review them:

$ hgpushsvn --dry-run

and submit (if you have commit privileges):

$ hgpushsvn

To produce a patch to the maintainers, use usual svn diff command:

$ svn diff > mybugfix.patch

4.1. Pros

4.2. Cons

Improvement Discussion

Mercurial interoperability with Subversion is clearly not as good as Git or Bazaar-NG one, and this is a real showstopper for massive adoption. The question is what can be improved and in which order so we move from "existing but tedious" to "usable".


CategoryHowTo