Of Microsoft Visual SourceSafe, and why to get rid of it

When I began work at my current employer, they were using Microsoft Visual SourceSafe for version control. This is the tool used by a great many small Microsoft software development shops - when buying an MSDN license to get the development tools, included in the pack is Visual SourceSafe. This makes SourceSafe a no-brainer.

Unfortunately SourceSafe is one of the weakest version control systems (“VCS“) around. I won’t go into details why not - if you want to know more, I suggest these articles:

• Visual SourceSafe Version Control: Unsafe at any Speed? by Michael Bolton (2003)
• Visual SourceSafe: Microsoft’s Source Destruction System by Alan De Smet (2002)
• C2.com’s Wiki page on SourceSafe

Some of these pages are quite old now, but so is SourceSafe. It sat at version 6.0 from around the late 90s until 2005 (with a few service packs along the way.) Visual SourceSafe 2005 then arrived, which fixed some of its limitations but without making fundamental changes. So you can still get SourceSafe today and it will have most of the problems and limitations described in the articles above.

So assuming you’re now convinced to move away from SourceSafe. To what? This is not a simple question - there are a huge number of version control systems out there.

Your first decision is to make the choice between the classic or distributed flavours of version control. Distributed version control systems - DVCS - are relatively new but have gained a lot of ground in the last couple of years. The highest profile project using a DVCS is Linux. Linux is developed in a highly-distributed fashion, with hundreds of developers all around the world, and a DVCS supports this style of development.

My knowledge of DVCS is limited, so I will refer you Eric Sink, an expert on version control systems, who has very recently written on the subject of DVCS, with some very detailed yet readable articles:

• Git is the C of Version Control Tools
• On Git’s lack of respect for immutability and the Best Practices for a DVCS
• DVCS and DAGs, Part 1
• DVCS and DAGs, Part 2
• DVCS and Bug Tracking

For now, I will concentrate back on the classic model of version control. This involves a central server, and each team member checks out from and in to a single central server. There is still a huge choice of software here - for an overwhelming list, see the List of revision control software article in Wikipedia.

However my choice of VCS is undoubtedly Subversion. This open source tool is built on solid VCS principles and has a great ecosystem of supporting tools.

In the next article I will explain how you can migrate your current SourceSafe repository into Subversion.

Edit: this post was originally titled Moving away from Microsoft Visual SourceSafe - Part 1