mkdir myproject cd myproject

The initialisation itself is pretty simple, just remember to point Git at the correct url for your Subversion repository, and watch the communication protocols.

git svn init -s --prefix=svn/ svn+ssh://svn.repository.com/svn/myproject

The -s option tells the repository to expect the typical trunk, branches and tags structure of a Subversion project. You can specify the location of your trunk, branches and tags using the -T, -b, and -t respectively.

Using the --prefix option is handy, ensuring that the remote directories will be prefixed with svn/. This makes it clear which are Subversion and which git branches later.

All that remains is to checkout all of the information relating to your project from the Subversion repository.

git svn fetch

Depending on the size of the project, this could take a while, it’s downloading the entire project history from the remote repository.

I word of warning you about the strangeness that can ensue if the remote repository contains any tags. They will be imported as git branches, and you may find the local master branch pointing to something other that the remote trunk.

These git svn commands, and all the others, are pretty well documented. Now I’ve got a Git repository, in the next post I’ll to describe my normal workflow.

Branching and merging is quick and simple, and as a result I find I do this far more often than when using Subversion alone. I also commit changes more frequently: it’s far quicker than using a remote repository, even when not off-line.

This sort of functionality is vital to successful version control, and I think it promotes better practice, as long as you’re only committing working software. All the local Git commits will later be bulk committed to the remote repository. However they all retain their identity as separate versions, so discipline is important, we wouldn’t want anyone finding broken code.

I could get all this from Git alone, but the combination retains Subversion vendor branching and the deployment advantages of my existing Subversion / Capistrano set up. I’m going to try GitHub, or my own remote Git repository, and exploiting the Capistrano support for Git, but at the moment why reinvent the wheel?

I prefer to work on the command line, and that’s the approach this series will take, but GUIs are available for Git, try typing git gui to check out the one bundled.

I use this approach for anything I need version controlled, including my Curriculum vitae/Resume, but before try this out for yourself you’re going to need to check out a local copy of that remote Subversion repository… I’ll cover that next time.