Any Real-Life Visual Source Safe Horror Stories

Question

VSS is much maligned and perhaps justifiably so. Please don't confuse me as an apologist for it, as I gave up on it a while back in favor of Vault.

However, despite using VSS for over 10 years on numerous projects with development teams between 3 and 10 developers, I never experienced (or to be fair, noticed) any data loss. I will admit it frequently reported corruption and needed repair, and was extremely slow over WAN connections, but I don't recall a single instance where I couldn't get something back that I needed in all that time. Ultimately I switched for performance reasons, lack of features, and general uneasiness about how often it asked me to run the repair utility.

Given the considerable sentiment that it is a source code destruction system, I was just curious to hear some first hand accounts of data loss and the circumstances surrounding them (i.e. Team size, Remote connections, project size) and the outcome (total data loss, partial data loss, were network backups sufficient to get it back?).

I am not looking for comparisons of it against other SCM systems, I am just trying to get a feel for how much of the tarnish on VSS is from first hand experience rather than legend.

Answer 1

• VSS abducted my daughter and sold her into human trafficking.
• VSS fixed the 1919 World Series.
• VSS bit off Evander Holyfield's ear.
• VSS created the Treadstone project.
• VSS is a cookbook.
• VSS ate the last donut.
• VSS killed Dumbledore.
• VSS created the Matrix.
• VSS gave me swine flu.

Answer 2

I've had many minor problems with it, mostly resulting in minor data loss. Quite often, I've lost up to a day or so's work where I thought something was checked in. I've also had several situations where a bug fix failed because of VSS check-in failure.

Finally, I also saw one case where the database on a really, really big J2EE project was corrupted and required a restore.

From a UI point of view, check-ins are quite unreliable and the feedback from the UI is often deceptive. You need to micromanage VSS checkins. Check very carefully, vetting each check in to make sure that it did actually get checked in. You also have to keep a close eye on where it thinks its working directory is and where the files are checked out to. This also means you need to keep an eye on your user.ini file in the VSS database directory and see where it puts its working directories.

Note that it only saves them when you exit, so you also need to exit and restart the front end.

Answer 3

We've used it for about 7 years, with a smallish team from 2 - 10 people, using remote connections storing afew hundred MB in it, and touch wood, it hasn't got corrupt once.

We run the repair once a month, but normally it doesn't pick up anything. To be honest I can't remember the last time it did pick up anything.

I've also used it before at other companies, and never had a problem with it.

Answer 4

We had a small codebase, less than 100K lines of code and it got to the point where once a week or so it would just lock up and would need to be repaired before we could check stuff in or out. This took hours.

It only allows one person to work on a file at a time, locking checkouts while someone has a file. If one developer went home with a file you need checkout out, it was an annoying inconvenience.

Disastrous performance when an office in another city had to check in or out (although of course this could have been our network setup instead of VSS but VSS was the only thing that seemed to have problems).

Answer 5

Aside from a situation where the VSS database was rarely checked (partly because it is such a pain to get everyone to disconnect and partly because it was not clearly someone's job), my favorite "horror story" about VSS involved working with a team located in both the US and the UK.

Basically there is a known issue where VSS does not deal with differences in timezone, all commits are made with the current time on the client machine. Working with a team that spanned timezones meant that code could be checked in and labeled by someone in the UK and developers in the US could come in to work and check in further modifications that would become part of that historical label because they were committed "before" the label was made (when comparing local time).

This only caused a few problems during the development cycle before we came up with a workaround (involving setting all the dev machines to UTC), so it's not a great "horror story", but it is a fairly frustrating bug.

Upon further reflection, I think the biggest horror story is how repeated exposure to VSS corrupts the minds of exposed developers because they "learn" that:

• Exclusive checkout is the only option
• Merging is dangerous and to be avoided (despite the fact that they have probably never tried to merge anything themselves)
• That source control is not to be trusted
• Branching is useless

Answer 6

Here's a blog post from Eric Sink (involved with Vault) entitled "Reasons to switch from Sourcesafe to Vault"

http://www.ericsink.com/SourceSafe_to_Vault.html

Pretty sure this will contain some good insights into why not to use VSS (even if it's somewhat biased)

Answer 7

I have 3 real-world, personal experiences with VSS.

• Many years ago, my department colleagues stored a large (several MB) Access db in VSS. Every so often it would be fetched from VSS only to find it was corrupt, and a backup had to be utilised.
• Recently, a department at work has several offshore developers using their central VSS db, this would regularly corrupt files (about twice a month)
• More recently, a colleague complained that a file was missing from VSS, turned out it wasn't actually missing - just corrupted and wouldn't fetch from the db.

Any one of these is a reason not to use it. They all have the fact that VSS is pretty much a network file-share with a fancy interface on top. If you check in a large file, or check in files across a WAN, you will get corrupt files in there. And the best bit is that you won't know which file is corrupt until you try to retrieve it.

Now, think how much you get paid to write software. How much would it cost to rewrite a chunk of code that VSS lost for you? Personally, I think that once was too many times - a SCM is there to look after your code, not act like a delinquent librarian who's always bunking off his job. Looking after your code is the first and only task you ask of a SCM (the rest is just nice-to-have). If VSS cannot do that reliably, its useless.

Imagine if SO was as reliable as VSS, if one time in a thousand it just decided not to bother recording your question or answer. You'd stop using it in disgust very quickly. Why people forgive VSS worse behaviour is beyond me.

Answer 8

This email came directly from an MS rep when we set him issues regarding branching, pinning and merging:

“The documented procedure you refer to will not work in your situation, despite what it seems to say there. I have reported this to our engineers and submitted a change suggestion to the documentation group. My understanding is that this procedure was appropriate before the integration of VSS and SourceSafe. Since solutions and projects now contain VSS binding, you cannot branch and pin this way anymore because the shared project can only refer to one branch.”

That was the last straw for VSS. They told us that if we wanted an enterprise solution (i.e. one that could branch and merge), we needed to get TFS. I bought Perforce.

Answer 9

One of the user (non-dev) departments here use a a complex 3rd-party configuration system / rules engine, that saves data in numerous xml files. We used VSS to store them (with backup etc), and all looked well.

A while ago I got involved to replace that 3rd-party product, so the first thing I asked for was access to the VSS... but it turns out that due to unfixable internal corruption, the only people who could use it were people who were already using it. If a new computer attempted to use it, it would just hourglass (I left it all weekend once, just in case).

Further; due to this, it turns out that the only valid and complete copy of the model we had was on an ageing, battered laptop that regularly commuted. When I heard that, I had a VisualSVN server running before the end of the day, with a commit from the single copy - and TortoiseSVN on all the clients shortly after.

So: we came dangerously close to losing the model on a mission critical application, but now we have:

• better tooling (much faster; harder to forget to add files)
• secure backups
• easier to access through code (my replacement project needs to migrate the model)
• better remote performance
• better (easier to access) change history

Answer 10

If you delete a file from SourceSafe, you cannot later add a file with the same name in the same location (developers sometimes change their minds). Well you can, but you have to use the admin facility to purge all history of the first file, which means that it will not be possible to retrieve the earlier revisions of the project in their entirety.

I also suffered with timezone problems and terrible remote performance. I spent 2 weeks in Sydney working on a project that was stored in VSS back in the UK. I couldn't commit for a fortnight.

I've previously blogged my SourceSafe experiences as a warning to others.

Answer 11

Several years ago, with VSS 6.0 (I think - it was the version that came with Visual Studio .NET), we were using VSS in a small team. I was using it across a VPN connection, working from home. This caused corruption, repeatedly.

The final time it happened, one area of our project was unusable for weeks, despite the engagement of Microsoft Tech Support. We finally got part of it back, but could not recover the rest. This was despite frequent repairs.

I've never used it since, except to migrate a customer from VSS to Vault.

The idea of not using a robust database system for source control is foolish.

Answer 12

I never really had a data loss issue when we were using it at work (now using SVN) but it is a real pain when you want to send a project to a different programmer outside your network because Sourcesafe injects its configuration right into your .sln and .csproj files which causes errors to show up on the other side since they don't have access to your Sourcesafe server.

Answer 13

We learned VSS had a limit on database size the hard way around the turn of the century (can't remember exactly). At least there used to be a bug in VSS where if your entire repository got bigger than some certain value, it would start to corrupt. No hints that it was happening or anything, it just gradually did.

Eventually then the repos got so corrupted we couldn't get stuff out any more. So we got the backup tapes only to find out that the backups were no good either. Eventually the only thing we could do was to go through every developers' computers and search for the latest file versions that way.

It took so much time that after that the company invested in a decent version control system.

Answer 14

This doesn't directly answer your question, but on reflection I think one of the reasons that lots of people use SourceSafe without ever encountering big problems is that unconsciously they avoid a lot of the problem cases. (A bit like when you're testing your own code. The QA guy here regularly does stuff with my applications that I would never dream of ("Are you crazy, don't touch that button?!")).

Things like checking in big binary files; working across timezones, or multiple development sites; trying to do 'clever' stuff like branches, working with change sets instead of files.

Answer 15

We have a small team here (2-3 people), which used to store its binaries in its VSS database. Their database grew over 6 GB (which is over the maximum size recommended by Microsoft) and get corrupted. It was too large to be repairable, so we had to restore a previous non-corrupted state and migrated them in anger under ClearCase. We probably had lost a couple of files when it happened. Most of the recent checkins/commits had to be retrieved from the developers' own environments.

Unfortunately, the ClearCase migration at the time was done wrongly, because of the VSS shares (see this other VSS question) that were not imported properly. So we had to redo the import in a different way a second time.

I would say we lost a lot of time and effort here, because of the VSS corruption first, and then the poor import mechanism from VSS to ClearCase.

Here, you got a real, first hand story. :)

I suppose the morale of the story is not that people shouldn't use VSS, or ClearCase, or this CM tool or that CM tool. It is to make sure that the tool chosen will fulfill the development requirements, and to monitor these requirements over time, as what was true 3 years ago may become wrong in the future.

If the team had been more aware of the VSS limits, they would have contacted the central CM team with their foreseeable problem before the corruption occured, we would have had the time to prototype a small migration and analyse the result of the export/import under ClearCase, we would have caught the shares problems, and then we would have planned and implemented the migration properly.

That's a lot of "we would" here, but that just proves the point that migration from one CM tool to another is not always an easy exercise, and can be long and costly. So they should better be planned rather than wait for your CM system to break to realise you have a problem. Which means you need to monitor your CM system properly, no matter its size, and re-assess its suitability each time there is a change in the way your company is operating (going from single site to multisite/timezones development, for example).

Cheers,

Thomas

Answer 16

We used VSS for years with VB6 code and had no problems. Now we're developing with C# (in Visual Studio 2008) it keeps losing changes. There are 2 of us working on an application with about 20 screens and we've had to duplicate so much work that instead of using VSS, we now copy the entire project manually to a folder on the network and retrieve it from there whenever we want to update it.

Answer 17

We used VSS for several years on a few small projects, eventually ending up using several gigabytes of HD space (this was expected as we had some rather large files within the projects, hi-res images and the like).

It was the night of our final submission (as always) for the project and I was just fixing a final tiny little bug in a file that was only a few KB in size. After confirming that the fix worked as expected, I went to check in the file. All of a sudden VSS crashes. We start desperately looking for why it went down (as we hadn't got our "build" machine to do the final build yet) and finally discover that we have run out of HD space on the partition that the repository is stored. With that discovery we were all quite relieved and deleted/moved a few GBs of obsolete files (unrelated to the repository). We started up VSS again and to my utter shock, EVERYTHING was at revision 1. We had lost ALL history on all files. After the shock of losing such a huge mass of information passed, we realized that the project was done anyway and we would probably never need that history again. I checked in my change, kicked off a build and then 2 weeks later we heard back from our publisher that the project had passed all of their QA tests and we haven't looked at the code-base since.

We probably could have recovered the info, but it really doesn't matter at this point (it was for a GameBoy Advanced game, so its burnt to a cartridge and would need a massive recall to ever do any actual maintenance). We continued to use VSS for a couple more years without a problem (though we set up some email alerts for when the drive fell under 1GB of free space) and then upgraded to Perforce which we still use today.