Revise the command line to ensure the software is installed correctly and to ensure all help is provided.
fix link to aragost kick start
|Deletions are marked like this.||Additions are marked like this.|
|Line 15:||Line 15:|
|* http://mercurial.aragost.com/kick-start/hgsubversion/||* http://mercurial.aragost.com/kick-start/en/hgsubversion/|
This extension is not distributed with Mercurial.
Author: Augie Fackler and co.
hgsubversion is an extension for Mercurial that allows using Mercurial as a Subversion client. See also WorkingWithSubversion.
TortoiseHg installs Mercurial and Subversion Python bindings required to run the extension.
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://bitbucket.org/durin42/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.
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).
You can use the usual Mercurial commands to work with this repository.
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
, and you can push the local changes back to the subversion server using
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