Why is Visual SourceSafe viewed so poorly?

Question

I'm interviewing this week for a position at a firm where I would be the sole initial developerplus support the application I am taking over work for. Because positions like this can vary so wildly in the details, I plan to go in advocating a number of specific approaches that would make the job workable.

One thing that I'm considering bringing up is an inclination to move the existing source code out of SourceSafe (where it is currently resident) into a better version control product like Perforce.

I've had a number of bad experiences with SourceSafe causing massive problems like permanent file lock-out and code corruption. Alone, I'm afraid that those anecdotes sound like "I want to change it because I don't like it." If I'm going to bring the subject up, I want to have a slam dunk case.

So, what are the empirical reasons that SourceSafe is viewed as an inferior product?

---

See also:

• Any Real-Life Visual Source Safe Horror Stories
• How do I convince my team to drop sourcesafe and move to SVN?

Answer 1

My last experience with Sourcesafe was years ago, so take this with a grain of salt. In my experience, it doesn't scale well as the number of developers touching the same code goes up.

There is no way to have multiple people working on the same code, and then merging their changes together on check-in. Instead, each developer has to lock the files they are working on, while the other developers can't make progress on anything touching those same files.

Answer 2

There's a long list of problems here (admittedly from 2002 but the product hasn't really changed since then)

Answer 3

Empirically, it makes no sense to trust your precious source code to a piece of software that isn't even up to the level of reliability as Microsoft Access. The product should have been dumped years ago. It's just not up to modern standards.

I'd rate it below any open source product like CVS or SVN, and I don't know of any product I'd rate below it, except maybe an older version of VSS.

Answer 4

SourceSafe is an antiquated technology built upon Windows shares. The storage mechanism (non-transactional "flat files") is a recipe for poor performance and bugs. Its adoption has nothing to do with what it has over other SCM's, and everything to do with the fact that it was "already there".

I can't comment on Perforce, but I can say that VSS compared to, say, Team Foundation Server is a very weak offering and should be used only in circumstances where there is already a large investment in it and NO money can be spent.

Answer 5

The big one that I've experienced personally is database corruption. It happens and it is painful. Aside from that, it's pretty slow compared to more modern SCMs.

If I were you, I'd recommend moving to at least TFS. The integration with VisualStudio is just as tight, it is much speedier, and the idiom is pretty much the same. I've had no problems with it in the 4 years I've been using it. Perforce is expensive and that's probably not something to toss around in an interview.

Answer 6

Microsoft does not use it internally. Instead, they got a source license to Perforce, and they've hacked it up to suit their needs. This is telling, since Microsoft proudly dogfoods their other products, like Windows and Office.

Answer 7

Back in 2002/2003 in a former job, I ended up being the guy who had to babysit our VSS installation.

We gave VSS it's own dedicated server - real physical hardware - in order to minimize disruptions, and still we had regular problems.

Once a week I had to go and fix broken locks - locks that couldn't be released by the developer who placed them.

Around twice a year I had to recover from a corrupted repository - there seemed to be some kind of built-in limit at around the 1G mark, whenever the repository grew much past 1G things went bad pretty quickly.

Given that there are better tools - with better integrations - that are now available at zero-cost, switching from VSS (to me) is a no-brainer.

Answer 8

I agree that VSS is a horrible piece of software but other than the possible database corruption problem, it seems like your situation will be a difficult one to sell people on. For example, you can't say VSS has terrible merge support because, well, you're the only developer. You can't complain about locking checkouts for the same reason. Unless your app is pretty good sized, you can't argue from the suggested 1 GB maximum database size that VSS suggests.

I personally think that in an interview like you're suggesting, you'd be better off looking for lower hanging fruit to suggest like iterative development, TDD or a wiki for documentation. I have fought the good fight to move from VSS to Perforce in an enterprise situation and that was hard enough. I can't imagine trying to convince management of a major source control change on an application that has one developer. YMMV.

Answer 9

See also Better SCM Initiative: Version Control Systems to Avoid.

One of the issues that I have read there, and I haven't seen mentioned so far in the answers, is that VSS has no support for deleted then recreated files: either you purge history of file (and can never recover old version), or you can create file with the same name as some deleted file had. Even CVS (which is also file-based) tried to did this right by using 'Attic' area.

Answer 10

Because it makes your source unsafe even when in repository.

Answer 11

1. Code Corruption (including your entire history stack)
2. Binary file corruption (we had this issue specifically with PDF templates)
3. Poor integration into Visual Studio IDE (very buggy)
4. Constant file lockouts
5. Did i forget to mention repository corruption...eeek
6. No branching

I can go on and on. The bottom line is to absolutely avoid this product. I think it may go well with smaller projects, but developing enterprise level applications should not involve dealing with constant codebase repository issues.