{{{#!wiki caution '''Not actively developed''' Please note that hgsubversion isn't being actively developed and may not work with the latest version of Mercurial. As an example, it does not support Python 3. If you'd like to help address this solution, consider [[ContributingChanges]] or reach out on the MailingLists. }}} == 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. 1. Alternatively: Mercurial >=1.3 + SVN >= 1.5 + ([[http://pypi.python.org/pypi/subvertpy|subvertpy >= 0.7.4]] OR the [[http://www.swig.org/svn.html|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 [[http://www.selenic.com/mercurial/hgrc.5.html|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 [[http://www.macports.org/ports.php?by=name&substr=hgsubversion|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 ([[https://bitbucket.org/durin42/hgsubversion/issue/110/memory-leak|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 $ cd $ cat >> .hg/hgrc [paths] default = ^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