Why would anyone not use source control?

Posted at 07:00 on 01 June 2009

There's a question over on Stack Overflow that asks if there are any good reasons for not using source control. It's a question I've been racking my brains over for a while now, especially since you do occasionally encounter people who claim they have good reasons not to. The most common such reason that I come across is that they're a lone developer -- an excuse that simply shows that they haven't a clue what source control actually is.

One person pointed out that physicists are particularly unlikely to use source control:

For the casual programmers - those to whom programming is just a tool, such as many of the people I work with (scientists) - much of the work is hackish and small scale, there may be a dozen other things that are more likely to fail outside the code which could also be eliminated with better practices.

As a colleague put it, "we don't get published for writing beautiful code".

Interesting point that. Most programs written by physicists tend to be no more than a few hundred lines long, or even just a Microsoft Excel spreadsheet, and once they're debugged and working, they usually don't change. This is of course the exact opposite of business and web programming, where requirements change faster than you can keep up with them. However, you can't really generalise here. I'd be very surprised, for instance, if NASA doesn't use some from of source control for the Mars rovers.

Another person gave an answer that was especially worth commenting on:

"For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is" --Torvalds

If you've got quick/easy/automatic backups, you've already got 95% of what most of us use VC for. Somebody with a local DVCS repository on his HD but no backups is actually in much worse shape.

Using a VCS does have a real cost, and it's usually a small one but not always. Every VCS I've ever used, I've had days where I had to fight with it for hours just to get it to do something that should have been simple.

To those that think "There are no good reasons not to use version control", where does it end? Must every project have 100% unit test code coverage? Must every project have code reviews? Coding standards? A complete functional spec?

There's a whole spectrum of programming projects in the world. Not everybody is writing code for the space shuttle. Sometimes being able to diff my code from 11:00am and 11:30am is simply not that important.

Some are merely managing globally-distributed teams of thousands writing operating system kernels.

This is another interesting point -- if the Linux kernel managed fine without source control for ten years, why should we use it? In actual fact, the commenter is not entirely correct: the Linux kernel has been under source control since 2002 and Linus Torvalds even wrote his own source control system because he was dissatisfied with all the others that were available at the time. But this is an indictment of CVS in particular, not of source control in general -- at the time the choice that you had was between that and something costing an arm and a leg.

This highlights another fairly common reason why people shy away from source control: they perceive it as being more trouble than it's worth. In recent years, most developers' first experience of source control has been Subversion. Once you get used to it, Subversion is pretty powerful and works very well, but unfortunately it is not a good example to throw at beginners when telling them they need to use source control. Getting your project under source control in the first place with it is a faff, and I've lost count of the number of times that it's gotten so confused with itself that I've had to do a fresh checkout just to get it working properly again. And all those extraneous .svn directories that pollute your project's filespace can be a major irritation at times.

So what is the best option to convince the naysayers? In a word: Mercurial.

Recently I've been playing with some of the new distributed source control systems such as Git and Mercurial, and I get the impression that they are much better suited to new and casual developers than Subversion. They're a lot easier to use for starters -- in combination with visual front ends such as TortoiseHg, you can get your entire project under source control with only three or four mouse clicks. They also have fewer pitfalls and gotchas -- you can rename and delete files and directories much more easily without creating a whole lot of confusion, for instance.

Another big advantage of modern distributed source control systems such as Mercurial is that they scale down as well as up. Mercurial creates a single .hg directory in your project's root which acts as a complete repository in and of itself. For a lone developer this is probably all you need, in tandem with a decent backup strategy, and it even makes it entirely reasonable to get your throwaway scripts under source control. After all, throwaway scripts have a rather nasty habit of not being as throwaway as we first thought they would be.

For development teams, you can have a central repository in addition to the developers' personal ones, and push the changes to the central server once you're done. For really big projects, you can have a whole hierarchy of source control servers, with changes being pushed up to the next level once they have passed quality control and whatever other processes you may have in place.

There may have been reasonable excuses for not using source control five years ago on small, trivial projects. But with the latest generation of tools, these excuses are getting flimsier and flimsier every day. Even for physicists.