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.
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.
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 it 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?
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 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.
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.))
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.
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.
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 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 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).
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.
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.
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.
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.
If you're considering SourceSafe, consider something else. If you're using SourceSafe now, migrate away as soon as possible. Here are just a few.
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.)
(Update 2007-01-08: Updated link to "Unsafe at any Speed." Thanks to R.H. for letting me know.)
(Update 2007-05-12: Moved list of control systems to own page.)
(Update 2009-01-05: Typo fixes.)
(Update 2009-04-15: Available for use under a CC-BY-3.0 license (see below))
Contact webmaster
- Copyright © 2002 Alan De Smet
(2002)
This
web page is licensed under a Creative Commons Attribution 3.0 License.
Attribution should be to "Alan De Smet". If possible a hyperlink to
http://www.highprogrammer.com/alan/windev/sourcesafe.html
should be provided, otherwise print the URL
"http://www.highprogrammer.com/alan/windev/sourcesafe.html".