# HG changeset patch # User Bryan O'Sullivan # Date 1240984190 25200 # Node ID 3edacbff2b43a1d8d1b58141badb520e9c0eb2ab # Parent fe31dc9ce44081aabfe59c527c5d86d9279e2e3e Add more details on Subversion conversion. diff -r fe31dc9ce440 -r 3edacbff2b43 en/appA-svn.xml --- a/en/appA-svn.xml Sun Apr 26 23:24:56 2009 -0700 +++ b/en/appA-svn.xml Tue Apr 28 22:49:50 2009 -0700 @@ -75,6 +75,41 @@ .hg/shamap inside the target repository. + When you want to start making changes using Mercurial, it's + best to clone the tree in which you are doing your conversions, + and leave the original tree for future incremental conversions. + This is the safest way to let you pull and merge future commits + from the source revision control system into your newly active + Mercurial project. + + + Converting multiple branches + + The hg convert command given above + converts only the history of the trunk + branch of the Subversion repository. If we instead use the + URL http://python-nose.googlecode.com/svn, + Mercurial will automatically detect the + trunk, tags and + branches layout that Subversion projects + usually use, and it will import each as a separate Mercurial + branch. + + By default, each Subversion branch imported into Mercurial + is given a branch name. After the conversion completes, you + can get a list of the active branch names in the Mercurial + repository using hg branches -a. If you + would prefer to import the Subversion branches without names, + pass the option to + hg convert. + + Once you have converted your tree, if you want to follow + the usual Mercurial practice of working in a tree that + contains a single branch, you can clone that single branch + using hg clone -r mybranchname. + + Mapping user names @@ -144,6 +179,70 @@ the repository, use . as the second argument to the rename directive. + + + Improving Subversion conversion performance + + You will often need several attempts before you hit the + perfect combination of user map, file map, and other + conversion parameters. Converting a Subversion repository + over an access protocol like ssh or + http can proceed thousands of times more + slowly than Mercurial is capable of actually operating, due to + network delays. This can make tuning that perfect conversion + recipe very painful. + + The svnsync + command can greatly speed up the conversion of a Subversion + repository. It is a read-only mirroring program for + Subversion repositories. The idea is that you create a local + mirror of your Subversion tree, then convert the mirror into a + Mercurial repository. + + Suppose we want to convert the Subversion repository for + the popular Memcached project into a Mercurial tree. First, + we create a local Subversion repository. + + $ svnadmin create memcached-mirror + + Next, we set up a Subversion hook that + svnsync needs. + + $ echo '#!/bin/sh' > memcached-mirror/hooks/pre-revprop-change +$ chmod +x memcached-mirror/hooks/pre-revprop-change + + We then initialize svnsync in this + repository. + + $ svnsync --init file://`pwd`/memcached-mirror \ + http://code.sixapart.com/svn/memcached + + Our next step is to begin the svnsync + mirroring process. + + $ svnsync sync file://`pwd`/memcached-mirror + + Finally, we import the history of our local Subversion + mirror into Mercurial. + + $ hg convert memcached-mirror + + We can use this process incrementally if the Subversion + repository is still in use. We run svnsync + to pull new changes into our mirror, then hg + convert to import them into our Mercurial + tree. + + There are two advantages to doing a two-stage import with + svnsync. The first is that it uses more + efficient Subversion network syncing code than hg + convert, so it transfers less data over the + network. The second is that the import from a local + Subversion tree is so fast that you can tweak your conversion + setup repeatedly without having to sit through a painfully + slow network-based conversion process each time. +