Top Eight Reasons to Abandon SourceSafe

How many of us work in Microsoft shops? I’m ashamed to admit that I do. When I took the job, I thought the benefits of working in a new domain with new technologies would outweigh the fact that I had to use Microsoft tools and program for Windows. Well, the benefits are real. The costs are also real. And one of these costs is SourceSafe.

The worst part about it is that there’s no particularly good reason why we have to use SourceSafe. But how many of us work in shops where everyone is scared to use a real source-code control system like Subversion or CVS? And all the reasons they give for sticking with SourceSafe really boil down to “Better the devil you know…” and “I’m too busy and too lazy to improve our technical environment.” (This is also frequently the substance behind the fear of automated builds, unit tests, and so forth.)

The best reasons I’ve heard to stick with SourceSafe is that you don’t want to lose your project history—but see #1—and that it’s tightly integrated with Microsoft’s IDE—but see #3. As I said, there’s really no good reason why we have to use SourceSafe.

So, direct from the school of hard knocks, here are the top 8 reasons why software teams everywhere, even in Microsoft shops, should abandon SourceSafe:

8. Links are dangerous.

Let’s say you have a branch, linked to a certain version of the baseline. Then check-out from the shared copy, SourceSafe won’t “branch” automatically. You have to branch manually, and if you do it wrong, you’ll end up checking out the wrong version of the file. I’ve personally seen this happen multiple times to multiple developers, and it’s a pain to fix.

7. You must check in changed files and add new ones in two separate operations.

This is just the nature of the interface. And it means lots of change sets checked in wrong. Because the changed files got checked in, but the new files didn’t get added.

The best you can do is

1. Find all differences between the repository and the project’s directory tree. (This will take a long time.)
2. Select and check in changed files from the list of differences.
3. Select and add new files from the list of differences.

That’s still two separate operations, but at least the changed and new files are listed next to each other. This means it’s more difficult to forget to add the new files.

Of course, there will frequently be tool-generated files you don’t want to add that will appear in the same list of differences. But you have to deal with them in any case.

6. Rollback does not undo a change.

It tries to undo changes. But rolling back a file breaks any links to that file, which affects other things in the repository. It is a myth that if you accidentally check in a change that you can “just go back to what you had before.” You can’t. What you need to do is:

1. Get an old version of the file.
2. Check out the latest version without overwriting the old version on disk.
3. Then check in the old version as an even newer version.

Of course, other source-code control systems either force you to do this or they offer a rollback feature that actually works.

5. Cross-branch merges don’t.

You want to merge all changes from a branch of a project back into the baseline. How do you do it? Short answer: You can’t. Long answer:

1. Find a file that’s been changed in the branch.
2. Click on the analogous file in the baseline.
3. Use the “Merge Branches” function.
4. Repeat for each of the hundred or so files in an average project.

Alternatively, you can get the branch into its own working directory and manually sift through the changes using a third-party merge tool.

4. You can’t tell which version a label applies to.

… at least not easily. The way to see the labels is through the project’s history. But the history only shows when the label was applied, not to which version of the file it was applied. So, label an old version of a file, then look at the history. It will look like the label is on the latest version of the file. But don’t be fooled!

The only way to tell what version a label applies to is:

1. View the file’s history.
2. Click on the label’s history item.
3. Click the “Details” button. This will show the version of the project the label was applied to, but not the version of the file.
4. Click “Previous” to display the details of the previous history entry.
5. Click “Next” to display the details of the history entry you actually wanted to see. Now, the display will show the file’s version, as you want.

3. Visual Studio isn’t actually integrated with SourceSafe.

Yes, Microsoft’s IDE supports SourceSafe commands, but these commands may or may not work as you expect them to—or at all. Depending on the project configuration, the project directory, your development directory, which applications are currently running, which instances of Visual Studio have recently quit and how they were configured, and the number of fruit flies currently airborne within 300 yards of your current location.

2. You can’t delete a file multiple times from the same directory without first destroying the file’s history.

You can delete a file once. Then you can create a new file with the same name. But if you want to delete the second file, SourceSafe won’t let you. First you must destroy all record of the previous deleted version. If you choose to do this, historical versions that use the old file will be incoherent. Alternatively, you can undelete the old file, in which case interim versions that expect the file not to be there will be incoherent.

1. You can’t trust SourceSafe to give you an historical snapshot of a project that will actually build.

There are so many ways to frell the repository, just don’t use it except with current development.—but see #5 and #7. Better yet, just don’t use it.

If a particular snapshot of the source code is important to you, for example, because it’s a released version, save a copy of those files in a more reliable repository, like a separate directory on disk.

In conclusion…

SourceSafe is one of those things average developers use. It requires a host of rules, workarounds, and trade-offs and generally just gets in the way. But we bear with it because it’s what we’re used to. And besides, the pain is not all that great. It’s kind of unfair for me to list all these problems in one place as though they were nagging at us every day. They’re not.

But they do get in the way. Average developers just work around the defects. Effective developers, however, make the computer work for them. They will put in the up-front effort to transition to a new tool if it means they won’t have to waste precious brain power hacking with it over the long term. That leaves more brain power to work on actual programming problems.

What’s the difference between average developers and the best developers? The best developers are perhaps more skilled. But skill is overrated. The biggest difference is that the best developers are more effective. They know how to improve the process in order to get the most important things done better.

And this is something that anyone can learn.

-TimK