Yesterday I spent a rather pleasant and relatively painless afternoon installing Subversion on one of Digital Aggregates' Linux servers. Subversion is the latest in a long line of version control systems, both proprietary and open source, to become popular. For me, version control has been one long strange trip which began with proprietary tools in the 1970s, adopting SCCS in the 1980s, moving to RCS, ClearCase, and CVS, and finally arriving at Subversion. We still keep our legacy C/C++ code in a CVS repository, but will keep at least all of our Java code in Subversion, and will probably use it to host future development of any kind.
I can't install, use, and manage a source code control system without knowing at least a little but about how it works under the hood. Looking back on my varied and hard-won experience in information technology and product development, I have come to the following conclusion: from strictly a user point of view, all of the version control systems I've used are pretty much the same. Yes, I can already hear the mob marching on the castle with flaming torches. But the fact is, there are a handful of basic things you always have to do when juggling multiple versions of digital stuff, and every version control system has to implement, with more or less success, the user's Platonic ideal of what such a system should do. Where they really differ is in how they are implemented, and what ancillary features they offer that take advantage of new enabling technologies.
Back in May I wrote about how architecture and design was driven not just by Moore's Law, which, broadly speaking, addresses just CPU horsepower, but also by similar exponential growth curves for things like network bandwidth, network connectivity, secondary storage density, and even bus width and speed. I argued that since these metrics were growing on very different curves, the architecture of today might not be the architecture of tomorrow, because what it took to design a balanced system would be so different in just a few years.
Version control systems have been victims of these different curves in a big way. Looking at how SCCS works versus how Subversion works under the hood, you can tell that the authors of both were looking at very different design points: "storage is expensive" versus "storage is cheap", or "development is economical because it is centralized" versus "development is expensive because it is distributed", "legacy code is relatively stable" versus "refactoring is a way of life" to name just a few. The legacy version control systems have not been able to keep up with the changing times.
And so, I am sure, in just a few years I will once again be installing and learning to manage and use yet another version control system. It seems unlikely, from a historical perspective, that Subversion will be the end-all and be-all.
The King is dead! Long live the King!
Ben Collins-Sussman et al., Version Control with Subversion, Subversion 1.2
Chip Overclock, "It's Not Just About Moore's Law", May 2006