Subversion

I don't often write about programming matters. I used to, back in the early days of this blog, but even then I didn't write much about the act of programming so much as some of my thoughts about doing the job right. It's one thing to be able to write a correct for loop; it's another thing entirely to know when to!

Which isn't to say that I think I'm the be-all and end-all of software development; far from it. I still haven't embraced the .NET framework in the way that Microsoft would prefer. I still think in MFC terms though I'm trying to break out of that mould.

Until very recently we used Visual Source Safe (VSS from now on) at work. We had the necessary plumbing (written in .NET forsooth) to access it across the internet; a necessity at the time we installed it when I was shuttling back and forth between France, Dallas, The Philippines and Phoenix.

I've been using source code control in one form or another for more than 20 years, starting with RCS on Unix, PVCS on the PC and settling on VSS because it was effectively free (included with MSDN). I even wrote my own incarnation of RCS back in 1988, using a bunch of command line utilities and PKZip. It worked well if somewhat slowly. Then again, back in 1988 everything worked somewhat slowly!

Anyone who claims to be a software professional and who doesn't use *some* form of source code control is claiming above their station!

To be honest, my experience with VSS wasn't nearly as bad as most users claim. I've never lost a file; nor have I ever experienced datastore corruption. This could be because I've always worked either alone or in relatively small teams; it's entirely possible that I'd have hated VSS with a passion had I been working on a large team.

But recently we've had a few new projects crop up that, whilst based on our current codebase, are sufficiently different that it made sense to create branches. Up until then it was sufficient to label each release in the database.

VSS makes it harder than it needs to to do the branching thing. Creating a branch is easy enough, but merging the changes back into the trunk some time later is a real pain!

Cue Coding Horror[^] and an article on Subversion. I'd heard of it; maybe now it was time to suck it and see. While I thought about it our VSS server at the office died. Server is a grand title for the machine; at 9 years old it was getting more than long in the tooth and it was only a desktop machine anyway!

So I scrounged a three year old Dell Xeon server with RAID. I managed to resurrect our old server long enough to import the VSS database using a freeware tool found here[^]. This was very important to me; I wanted to have our entire history available, not just the source to the last full release we did.

The migration wasn't a smooth process; there were one or two projects that refused to migrate. How fortunate that both were so out of date that no one, including myself, knows what they were for! I haven't been here forever you know!

In the end I decided to keep a copy of the VSS database on the new machine as well, 'just in case'. I doubt I'll ever refer to it but it's only a couple of gigs.

On the client side I use TortoiseSVN[^]. Wow is all I can say.