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!
Sources
Ben Collins-Sussman et al., Version Control with Subversion, Subversion 1.2
Chip Overclock, "It's Not Just About Moore's Law", May 2006
Subscribe to:
Post Comments (Atom)
3 comments:
No doubt Subversion won't be the last evolutionary step in version control, but it does offer significant benefits over contemporary solutions. For one thing, it's free, and it's a darned good tool for the money. Another benefit is that it offers project versioning vs. the file versioning provided by CVS and other tools. Finally, it's easy to install, easy to use, and, did I mention that it's free? Why some organizations would rather pay big bucks for a complex and substandard tool is beyond me.
I disagree with your angle you 'old coot'. If the features aren't worth dumping CVS for SVN then stay with CVS. Migration is driven by innovation, everyone has to do a cost/ benefit analysis when evaluating new software.
As a Mac user (yeah, I'm one of those guys), I also appreciate the fact that Subversion works on my platform of choice... easily. The expensive tool we use at work can be made to work, but not as easily. CVS is a great tool, but as the previous comment said, project versioning, including directories, is really helpful. I believe there is a nice CVS to Subversion import tool. May be worth looking at for your legacy code.
You can argue that this is subjective, but the Eclipse integration with CVS and Subversion also seems tighter than with the commercial tool we use.
And has anybody mentioned that it is free?
Post a Comment