Visual SourceSafe: Microsoft's Source Destruction System:

Visual SourceSafe: Microsoft's Source Destruction System

by Alan De Smet

There are many fine solutions for revision control systems. SourceSafe isn't one of them.

I used SourceSafe for five years though spring 2002 . It has consistently been an unpleasant experience. New versions failed to improve anything of import. I hope to dissuade you from using SourceSafe, sparing you the bad experiences I have had.
Missing Features
SourceSafe lacks usable branching support

A revision control system should provide powerful branching support. With strong branching support, developers can easily make minor revisions of old versions while work toward the next major release continues. Highly experimental code can be checked into a branch, keeping it separate from mainstream development but backing it up and making it available to other developers. If the project is "frozen" while a milestone or final release is built, a developer can continue development toward the next version on a branch. (Or more commonly, a new branch can be created for the freeze while general development continues on the main branch. When the release is done, changes on the frozen branch can be merged back into the main branch.) SourceSafe's branching support fails to effectively support any of this.

With powerful branching, a revision control system must also provide strong merging support to reconcile different branches. At the least, the system must allow a developer to examine the differences between two branches, modify them to create a merged version, and when satisfied check them in. SourceSafe's merge support is tightly integrated with checking in, making it difficult to examine differences and test the proposed merge before checking it into the tree. With this weak level of support, it's easy to check non-functioning code into the revision control system.
SourceSafe cannot be safely extended

It should be possible to easily extend your revision control system with additional functionality. The ability to send out emails summarizing check-ins is essential. When working with a team, regular email messages listing files checked in and the check in messages associated with them really help keep everyone up to date with recent changes. You might also want to add filters to prevent check-ins of code that doesn't meet certain requirements (standard copyright statements or doesn't compile). SourceSafe barely supports this. While is possible, every single client needs to have the additional functionality installed. If a single client lacks the extension, it will quietly fail to behave as expected. (For details, see Visual SourceSafe 6.0 Automation. Check the section "Trapping SourceSafe Events?An Overview".) You can pay even more for a third party solution, but does it make sense to invest more money in a fundamentally broken product?
SourceSafe silently leaves stale files on your local system

When updating your local workspace to match the server, files which were deleted on the server should brought to your attention. (Or deleted, since the old version can be retrieved from the revision control system.) Failure to do so risks out of date files being used in your project, often causing problems. I've frequently run into this problem when an out of date header file is incorrectly included into my project. SourceSafe fails to delete the out of date file or provide any warning.
SourceSafe badly handles slow networks and the public internet

SourceSafe is unusable over slow network connections. It's effectively unusable over the public internet. In addition, because SourceSafe works over network shares, if you place a SourceSafe server on the internet, you're exposing any weaknesses in your servers file sharing implementation to the entire world. Of course, if you're willing to invest more money in your ineffective revision control system, you can buy a third party product to solve this problem.
Managing third party modules is difficult with SourceSafe

It's not uncommon for a developer to use third party modules in your project to quickly add required functionality. For example, you might use Codejock Software's Xtreme Toolkit. It's natural to check these third party modules into your revision control system. This way, when you step backward in time to examine a previous revision, you can get the same versions of supporting libraries and third party modules that were used to build your code at this time.

Unfortunately, SourceSafe makes tracking a third party module extremely difficult. Initially checking the first version in isn't hard. Checking a new version in requires a good memory and attention to detail. To add a new version, you first recursively check the folder holding the module out. Now delete the directory on disk and replace it with the new version. Check in new version in. You now need to identify any files or directories added in the new version. Right click on the module's folder in SourceSafe and use "Show difference" to recursively generate a list of files which have been added. Note which directories hold files which have been added and which directories have been added. Now close the report of differences (the report is modal, preventing you from using SourceSafe while visible). Add the new directories as you would normally add directories. To add the new files, visit each directory holding new files and use File > Add Files to add them. Again, use the "Show difference" command to recursively generate a list of files which have been removed. Note these files and close the the report of differences again. Now delete each of these files in SourceSafe.

If you've actually tweaked the third party module, SourceSafe provides no particular help in tracking down the differences and merging them into the new version.

(For comparison, to check in a new version of a third party module using CVS, you would simply run the command "cvs -q import -m 'Import of Xtreme Toolkit 1.9' xtremetoolkit Codejock XT_1_9". That's it. If you've made changes to the module that need to be integrated, you would use "cvs checkout -j XT_1_8 -j XT_1_9 xtremetoolkit". That will give you a local copy of the merged changes which you can immediately check in if satisfactory.))
Viewing and retrieving historical versions is extremely slow

It's not unusual to need to get a historical version of the source code. You might need an older version to investigate a bug report, or the current code is malfunctioning and you need to get a functioning version. SourceSafe supports this, but it's extremely slow for non-trivial projects. To get a historical version, you first need to generate a history for the entire project you're interested in. On a project with hundreds of files and just over one year of history, this can easily take over five minutes (even if you restrict the actual search to the last 48 hours of changes). Once this history is generated, you specify the version to get by selecting the last check-in to accept. The slow speed at which this process is completed discourages developers from examining previous versions, defeating much the purpose of a revision control system.
Difficult to maintain multiple local copies of one project

While making extensive changes to a copy of the project, you may be asked to make a small change to the project. The most efficient and safest way to do this is to get another copy of the project to make the change on. SourceSafe presents two problems in doing so. First, SourceSafe only recognizes a single copy of the project on your system. You'll need to either move the project directories back where SourceSafe expects the canonical copy, or you'll need to reset SourceSafe's notion of where the canonical copy exists. Using either technique, it's easy to accidentally point SourceSafe at the wrong project and check the wrong versions of files in. Secondly, SourceSafe's weak merging features mean that if you need to change the same file in both copies of the project, you'll need to be very careful that changes to one project don't destroy changes in the other.
Safety
SourceSafe degrades on large projects

Microsoft recommends that your database not exceed 5 GB. (Source: Microsoft Best Practices) While this is a large database, it's not unreasonable for a large project, especially if you check in large binary files (like Microsoft Word documents).
SourceSafe integration can crash Visual Studio

SourceSafe can hang or crash when your system loses connection to the SourceSafe database. While this is irritating for Visual SourceSafe, this can cause you to lose work when Visual Studio is using SourceSafe integration. Simple having a SourceSafe managed project open in Visual Studio is enough to open yourself to the risk. To minimize this risk (and speed up ClassView), I suggest you follow Microsoft's directions on disabling SourceSafe integration.
SourceSafe relies on dangerous file sharing

SourceSafe doesn't really run as a server, but as a set of files shared over SMB. As a result, you're relying on each individual client to not misbehave. A single misbehaving computer can destroy the database. A problem in the file sharing implementation on your operating system can damage the database. Users only needing read-only access to the revision control system need write access to the server, increasing the risk (Required Network Rights for the SourceSafe Directories).
SourceSafe should be scanned for corruption weekly

Of course, with this high risk of corruption, Microsoft recommends that you run the Analyze diagnostic program weekly. (Source: Microsoft Best Practices) While Analyze is running all of your developers are locked out of the system (I hope everyone remembered to quit from SourceSafe first!). My experience with SourceSafe shows that a 2 gigabyte system running under Windows 2000 takes several hours to check if run weekly.
SourceSafe handles multiple time zones badly

If you have teams using the same SourceSafe repository in different time zones, you're likely to have problems. (See Microsoft's details on the time zone bug.) The only solutions Microsoft provides are to incorrectly set the clocks of the computers to a single time zone, or to purchase a third party product.

Relatedly, this is a potential problem if any of the client computers using SourceSafe fail to have synchronized clocks. Differences of several minutes between computers can cause strange behavior from SourceSafe with it tries to reconcile information that appears to come from the future.
SourceSafe becomes corrupted

Your revision control system must be trustworthy. You're entrusting your hard work to your revision control system. If your data is corrupted, the system is worthless. SourceSafe's fundamental design assumes that clients are trustworthy, always function correctly, and that nothing interferes with the communication causing corrupted data. As a result, SourceSafe is fragile and untrustworthy. I have worked with SourceSafe at three different jobs. In each case, eventually the SourceSafe database became corrupted. Data has been corrupted, work has been lost, time has been wasted on the problem. Speaking with other developers, I have learned that my experiences are not unique.
Irritations

*

Minor actions like changing the directory erase the entire contents of the output window, making it difficult to examine past actions.
*

Comparing your local version to the remote repository is clumsy. You select the directory you're interested in SourceSafe and select Compare Differences. The resulting report is modal, preventing you from working with SourceSafe while examining the report.
*

When getting the latest version of files from SourceSafe, each file changed locally causes a dialog to pop up to confirm the update. The update action entirely stops while the dialog waits for your response. This is particularly irritating if you get the latest version, step away from your computer for a while, then return to discover that SourceSafe is only 10% done and waiting for your response. You can prevent the dialog from returning in several ways, but in doing so you get no indication that any such files were encountered. So when you return to the finished update, you will have no idea that SourceSafe encountered potential problems. SourceSafe should note these files in the output window when encountered, making it easy to scan the output window for files to be investigated.

Conclusion

If you're considering SourceSafe, consider something else. If you're using SourceSafe now, migrate away as soon as possible. There are any number of options. Here are just a few options to check out. Most, but not all, are cross-platform, but if you're already using or considering SourceSafe, cross-platform support probably isn't that important. Note that with the exception of CVS, I don't have personal experience with any of these, so evaluate them yourself.

* BitMover's BitKeeper - Linus Torvalds chose BitKeeper to manage Linux, one of the world's most widely distributed development efforts.
* Reliable Software's Code Co-Op - Was suggested to me by someone at the development company. The web site suggests that a key focus appears to be distributed work; individual nodes are large self-sufficient. Occasional synchronization can be done over a network or email. It appears to share many of the goals of BitKeeper.
* CVS - CVS has its problems, but it's powerful, stable, reliable, transparent, and free (both in price and freedom). It's my current pick. If you're using CVS under Windows definitely check out the excellent (if complex) front end WinCVS. For something a bit less complicated you might want to see TortoiseCVS; it exposes CVS as a Windows Explorer extension. If you're experimenting with CVS for the first time you'll find the book Open Source Development with CVS useful. Despite the name the book is useful to anyone using CVS. Even better, the key chapters on usage are available free online.
* GNU arch - One of the newcomers to be Free Software options.
* Perforce - I'm not very familiar with Perforce, but someone from Perforce very politely inquired about being added. High speed appears to be a key design element. Looking over their promotional material, I get the distinct sense that they're targetting ClearCase users unhappy with the speed.
* PureCM - A relatively new system that appears to tightly integrate a bug/issue/change tracker. It also appears to support distributed changes (being able to check things in without access to a cenrtal server). On of their developers kindly asked to be included, so here it is.
* Rational ClearCase - I've heard it's big, slow, requires a custom file system, and really demands a dedicated administrator. But I know developers who swear by it's power. I gather that it's truly industrial strength source control.
* SourceGear Vault - I don't know a lot about SourceGear Vault, but they were nice enough to ask about inclusion in the list, so here you go. SourceGear developed the SourceSafe extension SourceOffSite, so they're clearly familiar with the problems in SourceSafe. They set out to develop a superior replacement. They promise the ability to import your SourceSafe repository with all historical information, useful if you're migrating away from SourceSafe.
* Borland's StarTeam - Another product I'm not too familiar with, but they nicely asked about being included. It looks like they're trying to integrate with lots of other commonly used tools like Microsoft Project. They provide a free evaluation download, the bad news is that they want lots of information, the good news is that you get to download it immediately instead of waiting for a salesman to call.
* Subversion - Explicitly designed to replace CVS as the open source source control system, Subversion is still under heavy development but is stable enough for production use.
* TLIB Version Control - Another addition at the polite request of the publisher.
* Computers : Software : Configuration Management : Tools - This DMOZ Open Directory Project category collects information on many source control systems. If you're considering a source control system it's definitely a good place to start.

If you simply must use SourceSafe, definitely take the time to look at Microsoft's list of bugs in Visual SourceSafe 6.0 and list of fixed bugs in Visual SourceSafe 6.0 so you know what to expect. (These links were originally taken from Microsoft's Bugs page. This page may be useful if you have a different version of SourceSafe or the above links fail.)