[clug] Using Mercurial/Git locally with Subversion remotely

[Alex Satrapa]

Here is a brief update on a presentation I did some time back, regarding working with a local/offline DVCS against a Subversion repository. The aim was and is to use your favourite distributed/offline version control system locally while interfacing to a subversion repository. The local DVCS will allow offline work to be under version control, so that while I'm on the bus, international flight, or stuck in some backwoods locale such as Charnwood, I can be productive and then bring all my changes back to the Subversion repository in an orderly manner.

My first attempts with git relied on "git-svn" which I found hard to use over time since it would rollback all the git commits, then replace them with new ones linked to subversion. This meant that merge history was lost, which is a big thing for people who want to use git to make life easier.

So the revised plan is quite simple:

Check out your subversion repository to Project/upstream, add your DVCS to that, then clone it locally for local work:

[alex at host ~/project]$ svn checkout https://svn.server.example.com/project upstream
[alex at host ~/project]$ cd upstream
[alex at host upstream]$ hg init
[alex at host upstream]$ cd ..
[alex at host ~/project]$ hg clone upstream local
[alex at host ~/project]$ cd local
[alex at host local]$ # do stuff

Now you can do your work locally, pushing the changes of interest back to the dual-VCS repository

[alex at host local]$ hg push
[alex at host local]$ cd ../upstream
[alex at host upstream]$ svn update
[alex at host upstream]$ hg update X # where X is the revision you want to update to
[alex at host upstream]$ # handle conflicts
[alex at host upstream]$ svn commit -m "Stuff I changed"
[alex at host upstream]$ cd ../local
[alex at host local]$ hg pull ; hg update

Whether you use git or subversion, the process is the same. All merges are retained in the local version, with the upstream version having none of the "collapsed and disappeared merges" problems of git-svn.

What I'm working on now is scripts to automate the process of extracting one commit at a time from the DVCS repository to commit them into Subversion in a sensible order (and in the process maintaining comments, so that links to Trac will be maintained).

As an example, I am currently working through six changes made locally, each refers to a different Trac ticket.

[alex at host upstream]$ hg update 30
[alex at host upstream]$ svn commit -m "Commit message for local change 30. See #77."
[alex at host upstream]$ hg update 31
[alex at host upstream]$ svn commit -m "Message for local change 31. See #68."
[alex at host upstream]$ hg update 32
[alex at host upstream]$ svn commit -m "Message for local change 32. See #79."
… (I think you get the idea)

Of course I don't use any of the 'advanced' features of the DVCS in the upstream directory, aiming to keep its revision tree as linear as possible. All the fancy stuff is done in the local working directory, with one branch/tree/whatever used as the place to collate local changes in preparation for "shipping" to the upstream tree.

HTH