Migrating SVN with Branches and Tags to Git

Following my love affair with Git, I’ve also started using a local install of Gitorious for private and commercial projects at Open Solutions. Before Gitorious, this meant setting up authentication and Apache aliases for each new Git repository which meant we were pretty disinclined to create repositories when we should have.

With Gitorious, it’s just a couple of clicks and we have internal public repositories, team repositories or individual developer private repositories. It’s grrrrrrreat!

Last night and this morning, I’ve stated a process of finding the many SVN repositories I / we have scattered around to import them into Git (with all branches and tags). Here’s the process:

Importing Subversion Repositories with Branches and Tags to Git

1. Create a users file so you can correctly map SVN commit usernames to Git users. For example, users.txt:

2. Now clone the Subversion repository:

3. Now we have all the SVN repository. We need to create Git tags to match the SVN tags:

4. Now we need to create matching branches:

5. To help speed up a remote push, we’ll compact the repository:

6. Then we remove the meta-data that was used by git-svn:

7. And finally, we push it to our own Gitorious server:

References:

  1. http://stackoverflow.com/questions/3239759/checkout-remote-branch-using-git-svn
  2. http://stackoverflow.com/questions/79165/how-to-migrate-svn-with-history-to-a-new-git-repository
  3. http://blog.zobie.com/2008/12/migrating-from-svn-to-git/

So I’ve Made the Switch from SVN to Git…

…and I’m bloody delighted. 

The straw finally came when Nick forced my hand for a project we wanted to release through our work in INEX. I was pushing for Google Code but he had his heart set on GitHub. Now, in fairness, GitHub has some SVN bindings but after some research, I decided to dive right in.

Now, there’s both a steep learning curve but also a complete change of mindset required from centralised source code management (SCM) with SVN to the distributed model of Git. In the end, most projects will decide on a canonical Git repository anyway which pushes you slightly back towards centralised but there’s still a world of a difference.

So, what’s so good about Git? Well, lots. But first and foremost is it’s exceptionally powerful yet simple branching and merging that just works. And works fast – remember, with Git everything is local.

One work flow that used to kill me in SVN was that you’d be implementing feature X but someone needed bug Y fixed immediately involving some of the same code. Getting just the fix for Y in was tough and complicated. And branching in SVN isn’t quick or simple. In Git, I branch from the main development branch for every new feature, bug fix, etc and then merge what I need between them and back into develop when they’re ready to be pushed back to the agreed canonical repository.

I’ve been so impressed with Git that I’ve moved an open source project we created in Open Solutions over to Github: ViMbAdmin. I’ve also forced the rest of my team in Open Solutions over to Git and migrated a number of customer projects already. And we’re reaping productivity rewards!

How we work Git for projects was taken from this excellent post which I would fully recommend: A successful Git branching model.

Useful Git Links: