Well, it’s been a week since my last post and it seems I’m writing about version control again, but this time with a more positive spin on things. SVN has served me well over the past couple of years but I’ve decided to make the jump to GIT for various reasons, not the least of which is the friendly peer pressure from some of my open source mates 🙂 Some of GIT’s features which appealed to me include its distributed model (which allows for flexible workflows), improved ignore settings, staging/stashing and seamless move/delete operations (which in my experience can be painful using TortoiseSVN).
So I got a GitHub account, installed MSysGit and TortoiseGit for Windows, had a go at creating my own repository and committing a few things, and all was well. So of course, the very next thing I tried was migrating the SVN repository for one of my projects (a Foobar plugin) whilst preserving the revision history. I first attempted this using git-svn clone (the recommended way) and it proved to be considerably more difficult and bug-ridden than I’d hoped. In the end, after hours of trying different combinations and hacking through Perl (I don’t even know Perl!), I switched to a more manual method. Nevertheless, I’m documenting a few of the bugs/errors I encountered because even though it didn’t work out for my particular SVN repo, chances are it’ll work for others, perhaps with the help of one of the workarounds below.
Migration can potentially be as simple as this, where SVN_REPO is the path to your existing central SVN repository and GIT_REPO is the path where the new GIT repository will be created.
git svn clone SVN_REPO GIT_REPO
This was the first error I encountered. As it turns out, git-svn is built against older Subversion libs (1.4-1.5) whereas my SVN repo was 1.6. This can be resolved by doing mirroring your repo in compatibility mode like this:
svnadmin dump SVN_REPO svn_repo.svn_dump svnadmin create --OPTION COMPAT_SVN_REPO svnadmin load --pre-1.4-compatible COMPAT_SVN_REPO < svn_repo.svn_dump
So I tried this:
I tried to diagnose the problem by tinkering with SVN repo settings and tracing back through source code to no real avail. But I noticed that if I called clone with an -r1 option to grab only the first revision, and then git-svn fetched each one individually using the same option, that error never crops up (in fact, none do)… but upon checking the GIT repo, it’s clear that its contents never advanced beyond r1.
So at that point I gave up and decided I’d be better off ‘migrating’ my repository manually… by creating an empty GIT repo to which I would commit the exported versioned files for each revision of the SVN repo, along with associated checkin comments. Painfully mundane, but 22 simulated checkins and half an hour later, I was reminded that the dumb solution is sometimes a decent option. And automating it through scripting would be a better option if your repo has a few gazillion revisions.