One of the cool trends I’ve seen is the use of distributed version control systems as “super clients” against Subversion. You suck down the entire history of a Subversion repository into a local, private repository, do all of your commits locally, make branches, experiment all you want, then “push” back up to Subversion again. On the internet, nobody knows you’ve been using DVCS (or that you’re a dog.) What’s particularly cool about these bridging tools is that they allow users to try out DVCS before deciding to officially convert a whole project over. Or, if a project happens to be using Subversion but you still want most of the power of a DVCS for local work, it’s a perfect solution.

For all the blabbing I’ve done about distributed version control systems, I’m still a big fan of Mercurial. Of all the DVCSes, I think it’s the easiest to learn for svn users. It has a small, tight set of commands, and the community which runs the project is polite and sane.

In any case, there have been a collection of Mercurial-Subversion bridges available for the last couple of years, but they’ve all been deficient in various ways: either not capturing svn history entirely, or being unable to push back to svn correctly (or only very awkwardly). So I’ve pretty much stayed away. But today I want to plug a new bridge written by a friend of mine (Augie Fackler) who finally did it Right: he wrote a bridge called hgsubversion which (1) uses the actual Subversion API to pull history down (which is faster, more accurate, and long-term sustainable), and (2) actually knows how to push changes back to Subversion correctly. I want the world to be aware of this tool, because I think it’s the first Mercurial-Subversion bridge which deserves to be promoted into the popular ranks with tools like git-svn.

The tool is still young and not generally installable by the public (i.e. you’re not going to find any magic .rpm, .dpkg, .zip or .dmg for it yet)… but here are my cliff notes if you want to start playing with it.

Requirements

The latest (unreleased) Mercurial

Local Subversion libraries, at least 1.5, with swig-python bindings built

A Subversion server that is 1.4 or later

To get the latest Mercurial:



$ hg clone http://selenic.com/repo/hg hg-latest

$ cd hg-latest

$ make

$ sudo make install



To get the latest Subversion python bindings:



$ # if you don't have a binary package for svn-1.5-python-bindings already,

$ # this is a summary of subversion/bindings/swig/INSTALL instructions:

$ svn checkout http://svn.collab.net/repos/svn/tags/1.5.3 svn

$ cd svn

$ ./autogen.sh && ./configure

$ make

$ sudo make install

$ make swig-py # make sure you have swig 1.3 installed already

$ make check-swig-py

$ sudo make install-swig-py



To get hgsubversion:



$ hg clone http://bitbucket.org/durin42/hgsubversion/ ~/hgsubversion

$ cat >> ~/.hgrc

[extensions]

rebase=

svn=/home/user/hgsubversion

^D



To make sure you’re ready to go, do a final sanity check:



$ python -c "import svn.core; print svn.core.SVN_VER_MINOR"

5

$ # if you get something less than 5, you may have conflicting

$ # versions installed, and may need to set PYTHONPATH



Now you can clone your favorite svn repository, and use it locally:



$ hg svnclone http://svn.example.com/repos hg-repos

converting r1 by joe

A trunk/

committed as 24dfb7b51d606a921333e2b8f19a9a6aa5661a69 on branch default

[...]

converting r100 by jane

M trunk/goo

M trunk/moo

committed as 54dfb7b51d6d6a931333e2b8f19a9a6005661a62 on branch default

$



The tool currently assumes a ‘standard’ svn layout of /trunk, /branches, /tags, and then tries to pull them into sane mercurial equivalents. After you’ve made a bunch of local commits, you can push the changes back to subversion: