Git, an Alternative to Subversion?
// March 12th, 2009 // Programming
One of the guys at work (Jimmy Tight Pants) suggested looking at Git as a replacement to Subversion having recently been playing around with Rails. Sort of in conflict, and in interest to the suggestion I thought I’d try out switching my personal subversion repository across to Git. Also I liked the chance of having a source control system called “git” (I pronounce it git instead of “jit”).
Firstly, I won’t explain too much about Git and who uses it. It’s easier just to pop to the website to read more about Git.
Getting Setup
I hosted Git on my Ubuntu Ibex Server. It was simple to setup:
sudo aptitude install git-core
Setting up a Git directory was quite easy. I had to SSH onto my server, then do the following:
cd /media/storage/dev/
mkdir repository
git init
In the above I’ve created a “repository” directory, and initialised it as a Git repository.
Next up I had to setup my client, a Windows 2003 virtual machine (using VirtualBox) for .Net development. To install Git on Windows I needed to download and install msysgit and TortoiseGit (v0.6.2.0) as the chosen GUI (as we’re used to TortoiseSvn at work).
When installing msysgit, I made sure I installed the bash, and command line usage. I also added the bash explorer context options. If you right-click on a folder in and select “Get Bash here…”. You’ll get a command prompt, you then need to enter the command:
ssh-keygen -t rsa
This will generate you a key in the .ssh folder of your user account (ie in C:\Documents And Settings\% USER %\.ssh). Next you need to get this key onto your server. I actually struggled to do this from Windows, and instead of install cygwin, I just copied it to a shared directory and used the Linux Terminal (I’m using a virtual machine in Linux to run Windows 2003 remember). To copy it to the server run:
sudo ssh-copy-id -i ~/id_dsa.pub robert@server
This should now have you set up. By having the key on the server, it won’t constantly ask you for password.
Using TortoiseGit, create a folder in Windows, right click on it and choose to setup a repository. You should now have one repository on your server, and one on the client.
Pushing and Pulling
As a test run I added a file to my client repository. This was simple with TortoiseGit and very similar to using TortoiseSvn. Firstly, “add” the file, and then “commit” it.
I decided to “push” the file to my server. Again this was relatively simple using the TortoiseGit menu selecting “push”. It allows you to pick which files to push to the server, just like when you commit with TortoiseSvn.
The harder part was getting the server url correct. When pushing, Git uses SSH to connect to the server, before performing the push. When asked for the server url I used:
robert@server:/media/storage/dev/git
Problems…
I had a few problems using Git, mainly related to the Windows port of it, and TortoiseGit. However, I have to use Windows, and we’ll be using TortoiseGit, firstly because it’s quick and easy to use, and secondly everyone is familiar with Tortoise Svn. The command line is very powerful but when it comes to commiting I still prefer a GUI.
- Custom SSH Port – I was actually originally using port 22000 as my SSH port on my server instead of the default port 22. However, when using this in the url robert@server:22000/media/storage/dev/git, it would always complain it couldn’t connect to port 22 despite me specifying port 22000 in the url. Not a huge problem, but annoying. I switched my server back to port 22 (I can use port forwarding still for a custom SSH port externally).
- TortoiseGit Speed – When moving my whole trunk across to Git I found it quite slow and a little unresponsive. I would right click to commit, get the file selection, and then click “Ok”. At this point it sort of freezes, the Ok button is stuck down and it’s just a matter of waiting. After a while it does respond and shows the files being commited/pushed, but it’s the pause prior to that, that isn’t very user friendly.
- TortoiseGit Commit Messages – when commiting with TortoiseSvn I like to be able to see the individual files as they get commited. With TortoiseGit it’s not quite so verbose which I sort of miss, especially when there are conflicts.
- No VisualGit – As a Visual Studio developer VisualSvn is a great app, and I can’t imagine being without it. Unfortunately there’s no TortoiseGit, and probably won’t be for quite a while.
Things I Prefer Over Subversion
- Less Clutter – A single .git folder as opposed to the per directory .svn folders that Subversion uses.
- Better Memory Usage – TortoiseGit uses (from what I can remember) less memory when storing it’s cache. Mine was typically running at about 8mb, whereas I’ve seen TortoiseSvn’s at around double that.
- Less Disk Space Usage – The checked out repository uses less disk space. Not really that important but I just liked that my checkout Git directory was 48mb, whereas my Subversion checked out directory was 90mb. That’s nearly a 50% saving. I guess it may help checkout speeds etc…
- Distributed Repositories – I don’t know if this will benefit our team hugely as we work closely in a Continuous Integration environment. It could even create an extra step as you have to commit locally, then push to the server, rather than just commit. However it’s still very handy. It makes branching locally much easier, and if working without an internet connection you can still revert and commit to your local repository.
Conclusions
At home I think I’ll keep trying it. It works well for my needs, especially being distributed (as I don’t expose my servers source control, let alone have it on all the time).
At work it may still be a while before which switch. Both msysgit and TortoiseGit are still in the early development stages and nowhere near as mature as TortoiseSvn. Having Subversion hosted internally, is fast and where very well, especially in a Continuous Integration envirnoment. The only benefit Git offers over this is branching locally, but at the moment we typically aren’t branching much. Plus we’d lose the use of VisualSvn.
It may just be a case of waiting a bit, and during that time trialling it in parallel at work.
