Why I’m Considering A Distributed Version Control System

I’ve been using Subversion for a good few years now, it’s saved my bacon many a time and I really believe that everyone should a Version Control System in place, however, whilst Subversion has served me well, I do have a few issues with it.

I’m not a fan of the way Subversion keeps track of changes, using the hidden directories in every directory you have. I’d much rather have it all in one place so that I don’t have to export everything, or worry when copying or moving folders.

Subversion doesn’t handle merges very well at all, and as a result I don’t create branches very often because I can’t be arsed with the headache I’m going to have later trying to merge it all back together.

Sometimes I’m not connected to the internet, and my repositories which are hosted on my domain, or at work can’t be accessed. This effectively means I can’t commit, which kinda leaves me stumped. :/

OK, so those are my main issues with Subversion, and it seems I’m not alone! I’m definitely moving towards a Distributed Version Control System for future projects. The problem I’m having is getting over the distributed part, there’s no master copy! I’m a bit of a control freak, so I like to know that there is one copy that’s right.

What I need to do is change the way I think about the process. In Subversion committing is like publishing, people can then see and check-out your changes. With DVCS you can have you own private copy of the repository and then you can merge in your changes to the ‘master’ one later. Because the repository is on your machine, you don’t need to be connected to the network or internet to do it.

I’m looking at the two big boys of DVCS: Git and Mercurial. Obviously I need to have an in-depth look at the pros and cons, and then a play with each before I decide. I’ll keep you posted!

Leave a Comment