I hate SourceSafe. I was once asked for my recommendation on how to best administer it. I replied "by using something else instead".
Version control systems
"Source control is like flossing - you don't have to floss all your teeth - just the ones you want to keep." 1
A "version control", "revision control" or "source control" system is a program that allows you to track changes to your files. This is important when the files are source code, so it is much used in computer programming. It's especially important on larger, long-running projects with more than one programmer working on them, and where losing code costs businesses money. However it is also a good idea to use revision tracking with your pet project that lives only on your home pc.
A version control system can tell you who changed what, and when. You can compare versions. You can go back to old versions in case you messed up the new one. When you check code in, it's stored on the server not just on your PC. It's a backup, and the other team members can then get the latest version from the server, and see what's changed. It's a safety net when you're working on your own and a way of disseminating changes on multi-user projects.
Source control will always be a chore, but it's one of the habits that separates professional software developers from slapdash coders. It is first on Joel Spolsky's list of twelve best practices 2. In this list it stuck out to me since unlike most of the other items on that list, it's not so much a rare "best practice" as a pervasive "entry-level" practice.
Microsoft Visual SourceSafe
Visual SourceSafe is a version control system. It is sometimes also called SourceSafe or VSS
. The first version that I used in 1993
or so still showed, on the program's about box, the logo of the company that Microsoft bought it from.
It hasn't changed much since that first version. It has a pleasant user interface – a calming yellow icon, a three-paned window showing a directory tree on the left, a list of files in the current directory on the right, and messages below.
Unlike in CVS, the default in VSS uses "exclusive checkout", meaning that you must check out a file before you can alter it, and if someone else has the file checked out, you cannot do so. You have to wait in line. It can be configured to allow "multiple checkouts" whereby more than one person can check out the same file at the same time. This is not as bad as it sounds, since the usual case is that your changes affect different parts of the file, and the merge program can reconcile them without any trouble. If it can't, it will ask you what to do. My recommendation is that you are using VSS, enable multiple checkouts – the added throughput is well worth the occasional merge.
Contrast this with CVS and Subversion, which in the default configuration have no concept of checkout. Every file is effectively checked out to every user all the time – you can change them at will, and decide if you want to check in those changes (after merging with any changes that anyone else has submitted in the meantime) or revert to the central copy.
Unlike Perforce and Subversion, VSS has no concept of transactions or changesets – each file check in is an individual event. So if I declare a new constant in
FileOne, and use it in
FileTwo, there is nothing to logically group those changes together, nothing to stop me checking in
FileTwo and not
FileOne. Indeed, even if I do what I usually do, check in
FileTwo shortly followed by
FileOne, it is possible to see the state of the repository between these two checkins, and get an source image that is not consistent even thought the code that I added was.
Unlike in Subversion, file deletes, rename and moves, and directory creation, rename or deletion are not versioned.
SourceSafe will fall over if the network connection it the server is broken. Perforce only needs to access its server when you use it.
As far as I know, only subversion has the ability to compare the working copy the last version committed, or to revert to it, without accessing the server at all (it stores a clean copy of all files locally). This is very handy if you are working on a laptop without any network at all. You will have to wait until you are next connected in order to update and commit, though.
Why use SourceSafe?
There are other source control systems: CVS, RCS, Perforce, Subversion, ClearCase, PVCS, Bitkeeper, Arch, Vault, git and others which I haven't heard of. The old unix standard of CVS is free, as is the new goodness, Subversion. So why is SourceSafe popular?
It's easy to use. It's from Microsoft. While technically it costs money to buy a copy, it is bundled with various packages such as Visual Studio or MSDN and so is effectively free to people who have already paid money to Microsoft. And it's included on the CD. It's seen as part of the same software suite. Hence it is widely used. By idiots.
The design problems of SourceSafe
"VSS, however, wasn't known for its scalability, stability, robustness, or the ability to work well across time zones and over the Internet."
- Microsoft documentation3
In all version control systems, the files under its control are stored in a "repository" on a server which the client program can access by some kind of network protocol. The basic design of VSS is that the repository is a collection of thousands of little files with utterly incomprehensible names, e.g. "
The VSS protocol is that the repository is exposed on a windows networking file share, and the client reads and writes the files as it sees fit. There is no server - everything happens in the client.
(takes deep breath) I'm serious. This is not good.
This fundamental design decision has two main consequences:
One, SourceSafe does not work across the internet, only across local area networks. Unlike Perforce, CVS and Subversion. A third-party add-on, called "Source OffSite" patches this.
Two, any client that goes wrong or exits unexpectedly can leave the repository in a bad state. Inconsistent, missing files, corrupt. There is no gatekeeper on the server side. Nothing to stop a client from falling over and taking part of everyone's version history with it.
This happens. Not every day, but give it time. Version control repositories are long-lived, frequently updated assets. It happens eventually, and if left untreated, it gets worse over time, like a slow leak below the repository's waterline. It also happens when the server runs out of disk space in the middle of some operation. It happens after branches. It happens more on larger, older databases. It happens if your network cards are defective. Sometimes it just happens and we never found out why.
Google search for
SourceSafe Corruption yields 22 200 hits today. Tens of thousands of people have written about this pain, and an order of magnitude more have felt it.
The first page of these results has some good links to documents from Microsoft on best practices to avoid corruption, and regular maintenance that you should carry out to fix the problems early. Like running the consistency checker weekly or monthly. On large installations you can't run it more frequently than weekly, since it doesn't finish on an overnight run. These onerous best practices are not widely used.
On Google you will also find pages from people who have used VSS and who hate it, and are happy to point you at an alternative that doesn't suck quite so hard. Revision control is good: every now and again your revision control system will save your behind. However VSS will also bite you there once every few years.
Many teams inside Microsoft do not use Visual Source Safe. 4
VSS was created in the early 1990s, before the Internet's flowering, so that shortcoming of not working over the internet is understandable. The second shortcoming of it being fatally flawed is not.
The state of the source-control art has advanced considerably in the period 1993-2006. However, SourceSafe remained largely static during this time. It hasn't even had the cosmetic overhauls that most Microsoft products regularly get. For instance, the "Add files" dialog is unchanged, and is difficult to use with long directory and file names, yet it cannot be resized. Compare it to the nice new resizeable ones used in Microsoft Office products since the late 1990s.
Well-understood software domains like this are likely to eventually go to a good free and open product which becomes a de-facto standard. Free and good is hard to beat. Microsoft has in 2006 recognised the challenge to VSS's market position from Subversion et al, and in typical fashion is trying to change the rules of the game. By adding value with integration and other advanced services. Hence Visual Studio Team System / Team Foundation Server (TFS).
I don't quite know what Visual Studio Team System does - apparently it's those Application Lifecycle Management and Unified Change Management buzzwords. But I know that it includes integrated elements of workflow, bug tracking, progress tracking and reporting, a build server, automated testing and a good-looking new source control system backed by a real database. An MS SQL server database 5, of course. It looks really hot, and rolls up a lot of current best practices.
But Team System won't be as free. And it is a more comprehensive, high-process product that may have a higher overhead than VSS. So despite VSS being deprecated (expect Microsoft to finally start pointing out its shortcomings when they push the successor) many people will probably continue to use it for "quick and easy" departmental revision tracking.
On the other side of the fence, Subversion really is quick and easy, and free and wonderful. You can use it on your own hard drive by yourself, or on a server with others.
You can integrate it with bugzilla for bug tracking and with CruiseControl and JUnit or NUnit for automated builds and testing for Java or .net. All for free.
Perforce is good too.
Paraphrased from Borland's Dave Scofield in "Live Chat on Thursday, October 21, 1999" at http://community.borland.com/article/1,1410,10492,00.html
2) "The Joel Test: 12 Steps to Better Code" is at http://www.joelonsoftware.com/articles/fog0000000043.html
3) from "Lap Around Microsoft Visual Studio Team System 2005" by Joel Semeniuk, Imaginets Resources Corp, September 2005
4) Rumour has it that they used Perforce and CVS. I'm guessing that they are all going over to Visual Studio Team System now, but in the period where VSS was Microsoft's main version control product (1993 to 2006), many product teams within MS wisely would not touch VSS, instead using a competing product from an outside vendor.
5) While VSS is one of MS's worst programs, SQL server is one of its best. Worst and best in terms of their technical merits that is, not considering price or closedness.
The Microsoft VSS best practice guide (i.e. VSS corruption and how to avoid it): http://msdn.microsoft.com/library/techart/vssbest.htm
And how to fix VSS corruption when you get it: http://support.microsoft.com/kb/q133054/
A programmer called Alan De Smet discusses VSS: "There are many fine solutions for revision control systems. SourceSafe isn't one of them." http://www.highprogrammer.com/alan/windev/sourcesafe.html
A programmer called Michael Bolton calls it "a dangerous, defective product that puts the data of its users at risk."
Joel Spolsky asks if you should use VSS or not. The replies are varied.
Jeff Atwood says: "If you are serious about the practice of software development, you should avoid SourceSafe. ... SourceSafe teaches developers bad habits: avoid branching, exclusive locks, easy permanent deletions.
TenMinJoe adds that he hates SourceSafe too.
I suggested starting a registry of those of use who hate it.
He replied: "You could save time and just ask MS for their list of registered users."