Control your Source, or else

If you’re a programmer, you should use some form of source control system. If you’re working on a project as part of a team, you must use source control. Let me reiterate that, if more than two people are working on the same codebase, that code should live under an SCM. No exceptions.

So what is source control? It’s a system that keeps track of every change to a directory and the files contained within. Additions, modifications and deletions are all recorded and (with some exceptions) fully reversible. What’s more, it handles all conflicts should two or more teammates be working on the same file at the same time.

New developers will often bemoan the use of source control. It’s a pain in the ass. Things break and they’re harder to fix. I don’t need the extra complexity just to edit this one file. It adds an extra step. Stop it with the excuses. Because one day, in the not too distant future, you’re going to find yourself using SVN or Git or any of the other options, and wonder how you ever worked without it. Consider these two typical days in a dev-house;

  • The non-SVN studio: Devs A and B are working on a new website. A has created all of the HTML and CSS and B is now tinkering with it, adding the PHP magic. As he’s working B adds some extra CSS to the stylesheet and carries on. Later on, A finds a bug so loads up his copy of the stylsheet and fixes them. He saves. B’s changes have now been overwritten. Hilarity/shouting ensues depending on the mood of both devs.
  • The new-fangled-SVN studio: Devs A and B checkout the new website from their repo. A and B do their respective tasks. A commits his changes, B updates and sees all of the new code. B modifies some of A’s code, commits it and A automatically merges it with their copy. Any conflicts the system can’t resolve are flagged up for a user to fix, normally very simply with most tools.

I know how frustrating option one can be, it’s happened a few times (and I’m normally the one overwriting files). Once you decide you want to use SCM, you have to look into the various options. The current favourite is subversion, otherwise known as SVN. It’s got a long history and widespread support in the form of applications and tools to simplify usage.

A new wave of systems are emerging though in the form of distributed versioning systems, such as Git and Mercurial. Rather than having a central repository (the place where all of the data is stored), each user has their own repository and changes are merged between them. The advantages of these systems are redundancy (everyone has a full copy, so there is no single point of failure) and much improved branching and merging (something that is very useful when working on multiple versions of a project). However, the current toolsets for these systems are still very young and not yet matured enough for everyone-use.

The secret to using source control is just that, using it. It’s far too tempting to just give up when the first problem arises. Once a project is in SVN (or Git etc), you can work on it just like any other file. All you have to do is remember to commit and update. And please, never commit a bomb. This is a massive change that affects a large portion of the system. Typically one would commit after adding each feature or area to an application, such that the commit message is descriptive enough without being overly long.

If you’re now tempted to get started with SVN or similar, good! Below are a few links, but you’re already well on your way to a better developers future.