When we started Iteracy back in 2007 one of the first things I did was set up a version control server in our office. This allowed us to keep track of all the changes we made to websites, and to ensure that we didn't overwrite each others code. There were two systems on offer at the time, SVN and the strangely-named Git. I'd used SVN at a previous job and it was easier to set up, so it seemed like the logical choice.
Fast forward ten years and we're still using SVN, managing close to 300 projects. There's nothing wrong with it, but in a classic Betamax/VHS format war, Git has definitely been crowned the king in the intervening decade. The feature that won the war was that Git is decentralised. This means that each developer can have their own version control system that tracks their changes, and also allows them to synchronise and integrate their changes into the larger project. It's just better.
Migrating from SVN to Git
As part of our regular security audits we're always looking to make our business more resilient to IT problems and attacks. And we also work with freelancers from time to time, who really need access to our version control systems. So it made sense to move from a locally-hosted SVN system to a remote Git repository. We chose Bitbucket but lots of others are available.
I spent a lot of time reading migration guides from SVN to Git, and eventually reduced down a lot of complex information to a few lines of code that effectively moved an SVN repository into Git. I wanted to share this with you in case you want to do the same thing!
We set up Bitbucket accounts for each of the developers and made a team for us all to make access easier. Then we made Git repositories through Bitbucket for all of the projects we wanted to migrate.
Bitbucket makes the repository name the same as the project name but in lower case with dashes instead of spaces, so you know that the Lovely Client Website repository is going to be called lovely-client-website. We installed Tortoise Git for Windows which was a breeze to get working and installs Git as part of the setup process. We've never been command line fans, but we had to get our hands a little dirty to complete the migration process.
First, you need an authors file. This is a simple text file that lists all the names of your developers who've worked on your SVN repos, because Git needs a name and an email address associated with each commit. A simple authors file looks like this and needs to be saved somewhere on your hard drive:
mat = Mat Connolley <email@example.com>
kat = Kat Smith <firstname.lastname@example.org>
To start off the process, open a command prompt and make a new folder to check out your existing SVN repository. Let's say we're using a folder at c:\wwwroot\my_repo :
Next, you'll need to make this your working directory:
cd /d c:\wwwroot\my_repo
and call git svn clone with the name of the SVN repo, where you want it checked out and the location of the Authors file. The parts in bold will need changing to your settings.
git svn clone "svn://servername/repo_name" "c:\wwwroot\my_repo" --authors-file="c:\authors.txt"
Depending on how many commits are in the repository and the size, it might take a while. I found that my computer easily handled doing four of these in separate command prompt windows at a time to speed things up. Once it's finished, set the address of the Bitbucket repository. We use HTTPS but you can use SSH too. The parts in bold need changing to your details.
git remote add origin https://email@example.com/team_name/lovely-client-website
That only takes a second. Finally, push out your changes:
git push -v --progress "origin" master
And that's it! In practice, it's much easier to make this into a batch file where you enter the SVN repo and the Git repo and then it does the whole thing at once. You'll need to set up some details but hopefully, it'll save you a bit of time :)