HgSubversion

hgsubversion Extension

This extension is not distributed with Mercurial.

Author: Augie Fackler and co.

Repository: http://hg.durin42.com/hgsubversion/

Additional information:

• http://hg.durin42.com/hgsubversion/file/tip/hgsubversion/help/subversion.rst

• http://mercurial.aragost.com/kick-start/en/hgsubversion/

Overview

hgsubversion is an extension for Mercurial that allows using Mercurial as a Subversion client. See also WorkingWithSubversion.

Pre-requisites

1. TortoiseHg installs Mercurial and Subversion Python bindings required to run the extension.

2. Alternatively: Mercurial >=1.3 + SVN >= 1.5 + (subvertpy >= 0.7.4 OR the Subversion SWIG Python bindings).

Installation and Configuration

The easiest way to install hgsubversion is to just clone the hgsubversion repository and then configure Mercurial to use it. Cloning the tip is recommended as it is much more stable than the latest tag 1.2.1 from march 2011.

hg clone http://hg.durin42.com/hgsubversion/ ~/hgsubversion

Configure your hgrc to enable the extension by adding the following lines:

[extensions]
hgsubversion = ~/hgsubversion/hgsubversion

Double check the extension is enabled via

hg help hgsubversion
hg help subversion

On Mac OS X, you can also install it with MacPorts.

Use

Most commands wrap their native equivalent. This is true for clone, outgoing, pull, and push . parents grows a --svn flag that shows the svn parent of a change, provided there are no merges between the current revision and the svn parent. Also, diff gets a --svn flag that changes the default "old" rev to the svn parent revision, and formats the diff to be almost identical to those produced by svn diff, making it suitable for tools that rely on that format.

Cloning a repository

Right now, you can only clone repositories that use a more-or-less standard Subversion layout. That is, the default location where work is done is called trunk, branches are located in a sibling of that directory called branches. Tags are expected to be another sibling of trunk called tags, but that is configurable.

To get a clone of the Nose project, start with:

$ hg clone http://python-nose.googlecode.com/svn nose-hg

The last argument, nose-hg is not strictly required, but because of how Google Code lays out projects, the default target would be named svn-hg which is not very helpful.

It is possible to discard old history by providing a --startrev XX argument, where XX can either be a revision number or HEAD. This will speed up cloning and reduce local repository size for projects with lots of history.

Cloning a large repository

There is currently (Jan 2011) a slow memory leak that can cause a regular clone to fail for large Subversion repositories (Issue #110). A work around is described in comment #6 of that bug. Assuming a bash shell, the process is something like this

$ hg init <repo_hg>
$ cd <repo_hg>
$ cat >> .hg/hgrc
[paths]
default = <svn url>
^D
# keep pulling until we succeed
$ until hg pull; do echo; done

Pulling New Updates

This will replay all the revisions from the Subversion repository into a new Mercurial repository. If nose-hg already exists, it will try to use that as a repository previously created with the same command.

This is analogous to a normal hg pull except that it will pull from the Subversion server instead of from a Mercurial one, and you can only pull incoming revisions in order. That is, you can't decide to pull just trunk changes, you have to get all of them..

If there are new revisions, and you have new revisions in your local hg repository, this will create a new head. The important point to note is that hgsubversion cannot push merge changesets to a svn repository. This means you should not try to merge this new head -- if you do so, hg push to svn will fail. Instead, you should rebase the changesets that you want to push to the Subversion repository (see Rebasing changes below).

Other Stuff

You can use the usual Mercurial commands to work with this repository.

Rebasing changes

If you have a series of commits on a given branch, and want to move them to the tip of that branch, use the following command

hg rebase --svn

while on the tip of your work, and those changesets will automatically be rebased over top of the new upstream work.

Pushing changes back to subversion

You can see what changes need to be sent back to the server using

hg outgoing

, and you can push the local changes back to the subversion server using

hg push

Issues and Solutions

• In some cases, hg incoming will show that doesn't have any of the changes that it should have already pulled. To fix this, run

  • hg svn rebuildmeta

CategoryExtensionsByOthers