The Future of Subversion?

Following a blog post by Ben Collins-Sussman, one of the original developers of Subversion, about the future of the open-source revision control system, Slashdot asks "is there still a need for centralized version control in some environments?"

Frankly - yes, there is. Just like we're always going to need one-bedroom apartments, even though most people end up getting a bigger place sooner or later. For some people, it's all they'll ever need - and for other people, it will always be an important stepping-stone on the path to bigger and better things.

I wrote my first program on an Amstrad 6128, many years ago. Committing a revision meant saving it onto a 3" floppy disk and putting it in a desk drawer. Tagging meant I'd write "dylan - hello.bas" on the label in pen instead of pencil, and then ask Dad for another disk. That approach - saving frequently and using offline copies for important milestones - got me through school, college, university and my first four years of gainful employment. These were all self-contained, short-term projects of one sort or another, and generally I'd be the only developer working on them. I didn't really get what revision control was, because I wasn't aware of having any problems to which it offered a better solution.

I should mention that, at university, they did teach us CVS briefly, as part of a ten-week course on "Software Tools and Techniques". Problem is, after that initial exposure to it, it played no part in any of the course material or assignments we did over the following two years - and we weren't really expected to use it except on the "learning CVS" assignment - so I think a lot of us, myself included, left with CVS filed alongside awk and sed as tools that were useful in certain circumstances but for which better alternatives existed for day-to-day development.

It wasn't until 2005, about twenty years after "hello.bas", that revision control actually become a day-to-day problem. One of my previous projects had turned into a full-time job, and we'd hired someone else - who also had no team development experience - to help out. At first, it was chaos. Our initial solution was using Beyond Compare (the nicest file comparison program I've used) to sync our local working copies against the live code. This lasted a couple of months, I think - until we hit a problem that meant rolling-back the code to a specific point, and neither of us had an appropriate snapshot. Whilst Beyond Compare was great, and simple file-comparison syncing was easy to understand, we needed something better. I installed Subversion, imported our codebase, and we've never looked back.

This is what I think makes Subversion interesting - and what guarantees a growing user base for the foreseeable future. It's a significant milestone on the road to becoming a better developer. I'm sure there's people out there who learn this stuff as a junior developer on a 50-strong team, with a sysadmin managing their BitKeeper repository and a mentor patiently explaining how it all works. I don't think they're the people we need to worry about. It's the people who have have already moved from simple copies to syncing tools, and are looking for the next step. When you start building a team around people who are used to working individually, revision control can get very complex, very fast, and I've found installing and running my own Subversion repository to be a great way to slowly get to grips with lots of the underlying concepts.