The VSS Mess

Microsoft’s Visual SourceSafe (VSS) will soon cease to exist. Mainstream support will end in April 2011, and so users will be forced to make the leap to an alternative: But which one?

Visual SourceSafe was bought by Microsoft to fill in a hole in their development IDE. It was originally a DOS command-line tool that was developed by another company in the late 80s as a rival to the then-dominant CVS and PVCS. It wasn’t much good at what it did then, and has been in decline ever since. Even when it worked, its pessimistic check-in/edit/check-out locking model was fundamentally unsuited to large-scale, agile team developments and yet many dev teams still persevere with it, partly out of a desire for a source control system that is fully integrated into their IDE (Visual Studio), and partly because there is no obvious alternative.

They might choose the open-source Subversion (SVN). Its server-based architecture can be used on all platforms, such as Windows Mac, and Linux, and is widely adopted and supported among developers. SubVersion is a good, conventional, well-proven solution that is integrated into Visual Studio and SSMS via third-party plug-ins. It supports branching and merging, but only if you are uncharacteristically patient as a developer: for the rest of us, the temptation is always to avoid them in SVN in favour of the straight-line death-march.

With Git, the distributed Version Control system for the wild men of IT development, branching and merging is, by contrast, an integral part of the system. Every developer maintains his or her own local source repository and so every each developer has their own branch that they can work on without affecting other people. Git is rapidly gaining in popularity. Linus Torvalds, Git’s creator, encourages the growth of a “network of trust” among developers, and a stronger determination to prove that a particular branch performs and scales better than another, and so should be pulled and merged by the rest of the team. It is free to use and surprisingly simple. However, no VSS or SSMS integration exists yet.

Microsoft developers will tolerate quirks in their Source Control system as long as it is integrated into the IDE and Team Foundation Server (TFS) would fit the bill perfectly. It is a complete collaboration package with version control, full integration with Visual Studio, SharePoint, reporting Services and so on. However, it has suffered in the past from four problems: It was expensive, handled merges awkwardly, had a painful installation ritual, and the upgrade path from VSS to TFS wasn’t smooth enough.

This has changed with TFS 2010. Microsoft has made a great effort to improve TFS and make the migration path from VSS less painful. The new “slot mode” version control mechanism is designed to greatly improve the handling of merging, change history, code refactoring and so on. The install has been completely overhauled; demos at the recent Tech Ed conference were at pains to emphasize its new “20 minute” installation process. The limited workgroup edition has been replaced by a $500 “basic” edition, which is identical to the full edition, expect for reporting and SharePoint integration. The full edition is now only $500, with 5 free CALs, plus $500 per CAL for each non-MSDN user. Finally, a proper VSS to TFS migration path has been established. It’s perhaps slightly more convoluted than one might have hoped; involving a number of preparatory steps, and some manual XML file manipulation, but it’s a start.

Cheers,

Tony.