Choosing your Source Code Management System

Source Code Management systems have been developed to ease programmers lives, not make them more complicated – as surprisingly some of them think. SCM’s are the answer to number of needs resulting from product development process, thus its selection should always rely on the project’s specific requirements. Today, the most popular SCM’s are Subversion, Mercurial and Git.

Each of them has its own advantages and disadvantages so the project’s requirements, development environment and team members receptivity should be taken into consideration. Relying on my own experience in project management and using version control systems to manage the development process I’ve formed the conclusions listed below that may be helpful while considering usage of one of described SCM’s in your own projects.

sizeof(Project)

When I released this article for the first time on the Ideas2Action Blog, I was asked how do I define the size of the project since this measure is used as a reference point when talking about mentioned SCM’s.

The answer is quite easy: it depends mostly on the amount of different and unique functionalities that are going to be implemented. For example a simple CMS providing the possibility to CRUD static pages and doing some tagging can be easily done in what I call “one man army mode”. That’s a type of a small project.

In a big project one have to implement many separate functionalities that can be spread among lots of hierarchically organised modules. Thus the work can be done concurrently  by several developers at a time (here a good change management and merging processes are required). In such situations it’s almost always required to provide the whole team with a stable snapshot of the project which will be a starting point for new functionalities – it’s extremely important in case of “agile” style of development where the actual project functionality priorities may change.

Subversion

Other obstacle of SVN is it’s way of merging changes (more on this can be Google’d – comparing SVN ang Git merging). It reminds me about C programming, where if you don’t have proper knowledge about the internals of the function / library, you’ll probably do something wrong and break the world. Recovery from such mistakes can be very hard and time consuming.

Moreover SVN is centralized - this can be a huge issue when the company loses connection with the server that holds the repository. In such case none of the team members can commit his own code changes what in practice means development process paralysis.

Mercurial

Recommended for medium and big projects (with accent on medium). With this system we can access to all the benefits resulting from distributed version control. Working with branches is quite easy and a good merging process allows efficient and reliable development. Moreover the distribution of the repository is a great support in critical situations, what is very important in both medium and big projects.

Git

Recommended for medium and big projects (with accent on big). Effective SCM usage relies on intense usage of branches in order to maintain changes moved from development phase to test and finally release. In case of Mercurial and SVN, creating a branch results (an pushing that change out to a “public” repository) in it’s appearing in other team members repositories. The same is with tags. It’s commonly required to get out of the SCM usage standard and create some additional tags or branches in order to separate working code from experimental one – even while developing a single feature (FDD). This can lead to creation of an experimental branch `user_acc_exp` next to `user_accounts` or additional tags named like `here_it_still_wokred`.

Thanks to Git and his branch tracking mechanism the working copy owner can decide which branches from the remote repository should be visible in his, and has the control over which branches are sent to remote repository for “public” tracking. This feature extremely increases the readability of repository’s contents which leads to increased usability. So if a developer requires a branch for his own – personal use, he/she can create one locally to maintain his own work without any notice for other developers (unless he/she shares this branch). If someone ever tried to fork, contribute to, or browse a real repository like NetBeans etc. knows what I mean – if not, one should try it once for a lifetime.

Compared to other systems (like in case any highly universal system) git was armed with a more complex command / parameter set. Despite increasing popularity (mostly thanks to GitHub) it still doesn’t have a nice and universal GUI (or none of them took my by the heart).

Actually I think a real programmer is not afraid of looking into the shell