Apostol Apostolov

Practical thoughts about software

Why bigger teams need Git/Mercurial?

An issue came up, a while ago, in the company I work for. The issue was that the development team was expanding. It was expanding because some of the projects got in later and more mature stages of development, which is a natural thing.

The expansion of the teams led to a interesting thing however – using SVN was becoming a pain in the ass. What do I mean by that?

Before the expansion - every project in the company had one developer who was working on it. That meant a linear development of the projects – if someone finishes a functionality, bug or feature, the project easily becomes ready-to-publish. With the introduction of more than one developer on the project - the company was able to build more than one feature per project at the same time. That process however broke the linear progression of the projects. When one person finished their feature – the second person could be half way through his, so if you need to publish the new feature you either have to wait for everyone to end their work, or hide the unfinished functionality.

I want to clarify that the way the company is using SVN is to have a folder for each project and commit your changes to that folder. A feature is a series of commits. It’s pretty standard actually and I think a lot of people use SVN that way.

In this context I began searching for solutions. And I actually found several solutions. The more interesting are:

  1. Introduction of branches in SVN – when you need to make a big feature – you make a branch and do the feature. Then you merge with the main branch.  After a bit of research on the matter however I found that this is not such a  good option.  Why? Well when merging in SVN, SVN tries to clash the two versions of the file you’re merging and combine them in one. So if someone has changed that file a little bit and you changed it  – you get a merge conflict. Now imagine a three or four weeks of work of one man trying to clash in three or four weeks of work of another. Disaster. This leads to the second option.
  2. Working with no commits. I mean you update frequently and  you commit when you’re ready with your feature. However – this means no one would be able to see your progress and no one will be able to help you with the feature. Also if you do something wrong at the end of the feature – you won’t be able to ‘revert’ your mistake. And it feels wrong too.
  3. Use a Distributed source control system(Git or Mercurial) instead of Subversion. I knew the distributed source control systems were better, but didn’t know why actually. So I began researching on the subject and found some great articles like the one from Joel Spolsky and this question in stackexchange, and a few others.

The big difference between SVN and Git\Mercurial and the solution of our problems was in the way the two source control systems worked. SVN tracks the VERSIONS of files and when merging - tries to unite the two versions you’re merging into one. Distributed source control systems like Git and Mercurial track the CHANGES in your files and when they begin merging they try to apply and combine every change you’ve made in your file with the changes the other people made to the file. That means that in theory – if you move a method and someone else changes the method contents without moving it – the source control should be able to figure that out and give you the result – the method moved and changed – without a conflict. That makes the merging of branches possible with very few conflicts. Nice. And that enables a lot of people working on the same features and changing the same files with a little effort and less pain.

It seems using a distributed source control system means you can SCALE  your development very efficiently. Very nice.

I think there may be a fourth solution to the problem – trying to implement a part of Scrum agile methodology – the Sprint. We set a target for a sprint and make changes(commits) throughout that sprint and in the end of the sprint we have a stable version of the system which we publish.  However that requires significant change in the processes of the company – of how we work, communicate, estimate and plan etc. It’s a lot more work and a lot more risk associated with this option.

After all we chose to use a distributed source control system – Git and particularly GitHub. It seems to have so much less pain associated with it compared to SVN.

However there is still the price of introducing it to the whole team, importing the source code from SVN and learning how to use Git PROPERLY. After all the source control is just a tool in the toolbox of a developer. And like every tool – if you don’t use it right it could give you a lot of headaches. But I think the whole effort will be well worth it at the end.


Posted By: Apostol Apostolov

Published at

Originally posted at


No comments posted yet.