Have you ever been really badly burned by VSS?

Question

I have heard lots of anecdotal evidence that using VSS is a horrible idea because sooner or later, it will just lose/corrupt/delete all of your work. (I am even guilty of using such evidence as one of the motivating factors to switch to SVN a while back). However, though I really prefer Update/Commit to Checkout/Checkin, it is horrible over SVN and there isn't good branching support, I have never actually had a catastrophic VSS experience.

Has VSS ever ruined your project/job/sanity? Old version or new? Is there truth behind the stories?

Answer 1

Our company started using it around 1995. We began phasing it out about 4 years ago.

[Editing to include the team as it was a "we were burned", not "I"]

Yes, We've been burned several times.

• Spent 2 or 3 weekends in the office baby sitting repairs on the repository.
• Spent 1 weekend about 5 years ago splitting the main repository into sub repositories because it finally got to brittle.
• Spent countless hours manually branching and re-basing code because VSS won't reliably allow this.
• Have lost some time due to corrupt files but that was years ago and I don't recall the details.
• Had to waste time and gas (there fore emitting CO2...) to drive into the office on nights weekends (during crunch time) to check-out files or view history because using VSS over a VPN is possible only if you wait 2-10 minutes per folder click.

As far as versions go, it was my understanding (correct me if I'm wrong) that 2005 was the last update and that was mainly on the client. The back-end (the critical end) is still a decade old.

If I think of more, I'll edit the answer.

BTW, I'm now a happy user of SVN.

Answer 2

Yes, but only in multi-user environments and only in the previous version.

The VSS becoming corrupted is usually quite obvious and can be easily restored from backup (take lots of backups) but there are conditions where in team use it forgets the state of something and allows edits to locked files or accidental rollbacks with no warning. This can go unnoticed for some time (especially if the tests get rolled back also) and is a lot uglier to clean up after time has passed.

I lost 9 months worth of work incrementally over a three month period once. That was my worst.

I switched to other source control before I had much opportunity to test, but the latest VSS was suppose to correct much of that.

Answer 3

No. But I have to say that it has been many, many years since I've used it (and I'm not looking to go back any time soon). For all of the bad things that I don't like about it, it never did hose any of my code.

Answer 4

Yes. I have had VSS repositories die on me. The last time was in 2002. There is some kind of a magic sweet spot between size of the code base, the number of projects and the number of developers that causes corruption. We wound up breaking things out into smaller and smaller separate projects to get stability, and did twice daily backups of all the files to protect ourselves.

Answer 5

From the SourceSafe plugins for MS Access, VB6, and two versions of VS.NET, I've had SourceSafe automagically revert check-ins to previous versions - losing my work. I finally was able to get our place on SVN and I'm a happier person.

Answer 6

I've never had a problem with VSS but did hear and read about it's lack of reliability :

A testimonial from the field :

http://www.highprogrammer.com/alan/windev/sourcesafe.html

Answer 7

Oh yes - the data files got corrupted several times. VSS is notoriously poor with maintaining binary files.

There's a nice blog post by Jeff Atwood

Answer 8

My team got burned by it, but it was a long time ago (mid-late 2001, IIRC). We ran out of space on the file server where the repo was stored. VSS cheerfully allowed us to continue to check things in, never giving any indication there was a problem. It started losing data around 10:00 and we didn't find out until sometime after 15:00. We restored from the previous night's backup, but we still wound up losing a whole day's worth of work.

Answer 9

Yes.

Once I spent a few days working on some rather complex changes to a large class (maybe a thousand LOC and several long days of pretty grueling work), and when I went to check in, VSS blew up and crashed, and corrupted the file. It basically turned my checked-in version into a pile of binary garbage.

We did do network backups which saved all the work on developer source drives every weekend, but this happened during week, so there was no backup. My only choice was to re-write that horrible, complex change from scratch.

Not as bad as cases where people lost entire projects obviously, but it was a particularly nasty change to have to re-do, and I was under quite some timeline pressure at that time. :/

Answer 10

We had many problems with corrupted databases using VSS 6 in a multi-platform Mac/Windows environment. It turns out this is a horrible known bug - Windows 2000 Server has difficulty managing locks consistently between different access methods (e.g. AFP and SMB), and VSS relies on this completely in order to work properly. We moved to CVS and then (more recently) to SVN and never looked back.

It baffles me why anybody still uses VSS when tools like Subversion are faster (particularly in WAN environments), more reliable, widely supported, and above all free!