An incomplete history of source code version control from SCCS to Mercurial

Once upon a time, in the 1970s, there was SCCS. It was big on PDP-11's and the like.

Then came RCS, which could do version control for individual files, but not for entire projects.

Finally, CVS arrived in the 1980s and people said "ok, finally we have something that can be credibly called source code version control."

And people used CVS for a good long while. And it was way better than not having version control.

But there were some problems.

Turns out that giving multiple people the ability to travel through time and alter the history of incredibly complicated documents with complex interdepencies can have a few wrinkles to it. Who woulda thunk it?

So, once we all survived Y2k, SVN was created, to be pretty much just like CVS, but working correctly.

Whole teams could work on projects, and fork, and branch, and all sorts of lovely things, all out of a central repository. A rich ecosystem built on SVN; IDEs integrated SVN functionality; issue tracking systems linked in so that commit messages could update the status of bugs; and vice versa. And not only is it well understood how to operate the software, even the business processes around code management using SVN are well understood and documented - for example, a very pragmatic book about it.

And that went pretty darned well for a good long while. Talk about mature!

But then Linus came along and started an open source project with thousands of contributors all around the world. Mind-bogglingly large scaling issues here. In fact, it had to be distributed - there couldn't be a single central store. And this just exceeded SVN's capabilities. 

So Linus created Git. And lo, Git is mighty. It can handle just about everything you can imagine. It's used by nearly everyone who operates at that scale, and all the open-source hackers who want free hosting at places like Google Code and Github. The best practices are mature.

So, here's the state of play these days:

SCCS and RCS are legacy software, like COBOL - still plays a valuable role, but generally not chosen for any new implementations.

There are old CVS implementations out there, often cursed at by the poor programmers who haven't been able to convince their management to upgrade to SVN. CVS is kind of the Internet Explorer 6 of version control systems these days.

Most enterprises have at least SVN (or some commercial equivalents, like the version control built into Visual Studio) and it's hard to think of an IDE with version control support that doesn't support SVN.

Many modern IDEs have added native support for GIT; tons of tech companies are using it. Including some folks who are pretty hard-core.

And there's an incredibly elegant system called Mercurial (Hg). Many people like to compare and contrast Git and Mercurial.

So, here we are, with Subversion, Git and Mercurial as obvious choices to select from, whether you're an open source project looking for free hosting on Google Code, a one person iPhone developer, or a Fortune 500 company.

If you care, here are links to my delicious tags for:

Version Control

Subversion
Git

Mercurial

(Did you notice I only discussed open source version control systems? Yeah. I said it was incomplete.)