Source Safe Problems

Microsoft Visual Source Safe was a Source Control System developed in the 90's and largely adopted by most Microsoft-platform developers by that time. It's still being used today in many companies, but there's no reason to continue using Source Safe when there are so many free alternatives that are vastly superior and safer.

Here is a detailed list of all known problems of using Source Safe

• SourceSafe gives you the illusion of safety and control, while exposing your project to risk.
• SourceSafe teaches developers bad habits: avoid branching, exclusive locks, easy permanent deletions.

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.

Bad support for Deleted files
When updating your local workspace to match the server, files which were deleted on the server should be deleted on client but they are not, they remain as stale files forever.

Bad support for Renames and moves.
A file that has been renamed will not be retrieved properly from the database for versions before the rename. When you share a file with another project and delete the original, you also lose its history. For Project moves, you get a Moved From action in one project and a Moved To action in the other project. When a file has been moved from one project to another, the action that you receive is not "Moved" at all. Instead, you receive the action that a file was shared in one project and then deleted in the first project.

SourceSafe badly handles slow networks and the public internet SourceSafe is unusable over slow network connections. It's effectively unusable over the public internet. And that REALLY matters these days with remote workers.

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.

Almost impossible to work with multiple local copies of one Project
In most version control systems, the local copy points to the origin server where it's binded. With SourceSafe that's the opposite: the server folder points to the local copy of each user. In other words: you can only keep a single copy of a project, and cannot easily move it around.

Indecent API
VSS API is weird, majorly undocumented, and full of bugs.

Safety

SourceSafe degrades on large projects
Microsoft recommends that your database not exceed 5 GB. While this is a large database, it's not unreasonable for a large project, especially if you check in large binary files.

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.

SourceSafe relies on dangerous file sharing
SourceSafe doesn't really run as a server, but as a set of files shared over SMB (network share). 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). Viruses can completely destroy not only your client computer but also your server repository.

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. While Analyze is running all of your developers are locked out of the system (everyone must remember to quit from SourceSafe first!). My experience shows that repositories with a few gigabytes takes several hours (usually the whole night) to check.

SourceSafe handles multiple time zones badly
Since each client is responsible for everything, there is no such thing as a "server time". Each client tracks it's own time, and even with users on the same timezone, you can easily lose files if all computer clocks are not synchronized.

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 many different jobs, and in all of them eventually the SourceSafe database became corrupted. Data has been corrupted, work has been lost, time has been wasted on the problem. If you speak with other developers, you'll hear similar experiences.

Annoyances

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.

Make the switch to team system, subversion, or any other modern source control system of your choice, but whatever you do, please don't use visual sourcesafe.

Reference #1
Reference #2

Move away from Source Safe right now

Migrate to Subversion

Krepost is our flagship application which provide a painless migration of your historical source-code from SourceSafe to Subversion.

Subversion is the obvious choice for most corporations who like to keep their source code in a centralized location and granular access control.

Learn More