Since time of yore, Microsoft Visual Source Safe has been our version control software of choice. No one is really sure why, but probably because it came free with Microsoft Visual Studio way back when VB6 was in its prime. And, when you look, actually, it wasn’t such a bad choice… back then. There was probably only CVS that could have rivalled it.

Cut forward to today, September 2008. Here we are, still using MS InterDev to edit our VB Script & classic ASP web pages, stored in our MS Visual Source Safe database. Not the image of cutting edge it could be remarked. In fact, mentioning this to most geeks would probably produce a stutter, a light cough and a snigger of amusement – followed shortly by a tarrade of insults and jokes. Well times are a-changin’! In the coming months we are looking to progress forward and create ourselves a presence in the 21st century! Yep, C# and the .NET framework! Fantastic! Wooo! Jolly brilliant and all that!

Having known about a number of different version control systems existing, I decided to have a quick nosey around and see what people suggested, and boy was I surprised!

Maybe not much of a surprise that a Microsoft product wasn’t the most popular product on the market, but what surprised me was the amount of hostility to it. Spend a little time just browsing around Google for information and comparisons between the various version control systems leaves very little to be desired regarding SourceSafe. Indeed, Jeff Atwood (from StackOverflow) declares “Source Control: Anything but Source Safe!“, which is quite a statement considering how well known and estabilished SourceSafe actually is. From my time looking around, I struggled to find anyone actually supporting the use of it – they were all desperately trying to find reasons to get away from it. Bizarre…. or is it?

When I read through the comments and wealth of moans & gripes about SourceSafe, I started to realise that we have had quite a lot of these problems. But we had either never realised they were errors (“it’s not a bug, it’s a feature!”), or just thought that we were unlucky. We have problems maintaining our users, sure at times. We have had more than our fair share of corrupt databases, that’s definitely true. We have even had issues where collegues have swore blind that they’ve checked things in and out again, but SourceSafe hasn’t made a version update. I’m starting to believe that they weren’t remembering it wrong and that actually, it might have been SourceSafe after all…

The biggest thing I spotted when reading through all the articles, was the difference in the way people use version control systems compared to how we use SourceSafe. It’s not surprise to me, in fact, I probably already knew that we were never really challenging our system to do things. We simply used it as a panic button in the rare instance where we totally messed something up, we could just log into the SourceSafe admin and restore a copy of the file. Genius! No need to talk to the server maintenance and ask them to restore a 3Kb file. However, the more I look at SubVersion and how it has improved and basically, its feature set, methodologies and so on – the more I realise: “Why the hell did we continue using SourceSafe for so long?!”.

Just to emphasise my point, here are some of the things that I believe could be selling points to try and move our development environment onto SubVersion and away from SourceSafe:

• Branching: the ability to take a snapshot in time of the working code and either work on it seperately, or prepare it for release.
• Merging of Changes: If any last minute fixes are applied to the release candidate code/branch, they can be merged seemlessly into the development branch of the code. Human’s may not even need to go into the code to edit it! In fact, they don’t even need to remember what changes were made due to the conflict detection.
• Web Access to Repository: The ability to view the source code & branches over the web appears to be apparent in SourceSafe also now, but this is a great bonus compared with before.
• Point-in-Time Code: I can create a branch of code based on how a specific branch of code was on a specific date, or based upon the code that was deployed in a specific release. This is a brain-exploder! Project-A is in development and two weeks after the first release, a bug has been found and needs an emergency patch. The development environment is no longer in-sync because we’ve been doing updates. No problem, give me copies of the project from the Version 1 release please. Fix bug, make it live, then merge the change into the development copy if its still there.
• Atomic Commits: This is the biggest bonus in my eyes. It basically means that if you’ve changed loads of pages/code, and one of the pages you try to change causes a bucketful of errors – all the other pages haven’t been made live. Imagine all the issues that would arise if it was a the Database Access class that had failed to update – all the pages that required it would be live – causing errors – until you either reversed the process or fixed the problems. No problem with Atomic Commits – just take your time, fix the issues – it’ll only go live when ALL pages are fine.

There are of course other perks, such as user administration being apparently easier in SubVersion. But for the process of trying to understand the differences – those points are to me, very significant!

It’s all very exciting this version control lark!