Converting a company from SVN to Hg?

Question

We're a heavy user of SVN here. While the advantages of GIT over SVN made us want to change, the advantages of Hg over SVN mean it's now time to change and we need to start doing so very soon.

I'm not so worried on the client side, but here are my questions.

1. There are some excellent books on setting file metaproperties, properly organizing projects, etc on SVN. What is that book(s) for Hg?

2. Is there a way to convert an SVN repository (that you've used) and can report how well it went? We don't want to lose years of commit logs if possible.

3. When you DO convert, how did you split up the old code? Did you commit trunk as one project, and tags/forks as another?

4. If you used SVN for legacy work, did you check in updates to SVN or something else?

Answer 1

1. There's a free book available at http://hgbook.red-bean.com/ and published by O'Reilly in 2009.

2. As of release 0.9.5, Mercurial comes with a conversion tool.

3. I must admit I switched to Git instead of Mercurial. That said, with Git you can import branches, tags and trunk at the same time in the same repository. Git takes care of everyone and gracefully stores tags as tags, branches as branches and the trunk as the master branch. I'm confident it's almost the same with Mercurial.

4. I recommend you to switch to Mercurial (or Git or any other DVCS) as soon as you can. Do not continue to work on two different repositories. When I switched, I kept svn as long as I was confident enough with Git (git-svn enables yout to interact from git to svn and viceversa). Then I made the switch and I locked the SVN repos.

Answer 2

There's been a discussion (pro v con) about distributed Subversion, some of it concerns items that SVN doesn't do as well as DVCSs, and vice-versa, but there's a lot of information in the long discussion that is of a useful nature to anyone thinking of migrating a company's VCS.

To skip directly to a good post, try this one.

If you do decide to go for a DVCS from SVN, perhaps you should look at git-svn which allows bidirectional changes between svn repository and git frontends. It should give you the best of both worlds, though using git instead of mercurial.

Answer 3

Please start by going to the Mercurial wiki. There you'll find a prominent link called Mercurial: The Definitive Guide which links to the hg book as it's called. You probably know the svn book for Subversion -- this is the equivalent for Mercurial (they're even hosted on the same server, but written by different authors).

Further down on the wiki front page, you'll find a section for refugees from other version control systems. There is a link with information for SVN users and repository conversion. The former explains that you can try HgSubversion if you want to do a bi-directional conversion between Subversion and Mercurial and the latter explains how to use the convert extension to do a (possible incremental) Subversion -> Mercurial conversion.

Did you find any of these pages already? If not, please tell us how we can improve these pages in order to make these things easier to find.

Answer 4

I've started the conversion from Subversion to something else a couple of times, once to Darcs, and now I'm playing with Git. I also did a fairly major move from CVS to Subversion quite some time ago.

My biggest piece of advice is, don't do it all at once. Pick one non-trivial but not huge project, and convert that first. Allocate a reasonable time budget (an hour per day per developer for the first couple of weeks is not unreasonable) for learning the system and adapting your workflow. A month or so later, once you have a reasonable amount of experience with the system amongst several developers, then you can look at converting everything else, if you still feel you even want to go that way. When you do that, make sure that your developers who are experienced with the new VCS are available to the others, ideally one should be working in the same room with anybody who is being converted.

Oh, yes, and this does presume that you've already done a reasonable amount of playing with the system, and built a "toy" project using it. Not too toy, though: it should involve at least three developers, a few dozen files, hundreds of commits, and should use a workflow similar to one of your real projects.

Answer 5

I had a rather large subversion repository where every main folder was a module. To split it up I used the following incantation:

for i in *; do \
    echo include "\"${i}\"" > /tmp/hgv.map; \
    echo rename "\"${i}\"" . >> /tmp/hgv.map; \
    hg convert --filemap /tmp/hgv.map /mnt/e/sqlwork/ "/mnt/h/work/${i}"; \
done

It gets every folder in the current directory, generates a filemap for the convert subcommand and converts the directory into a hg repository. I had no history-loss and hit no other obstacles. You may want to have a look at the convert extension.