Tuesday, April 05, 2005 5:37 PM
jerdenn
Build Failed: Visual Source Safe corruption
I really, really dislike Microsoft Visual Source Safe. I've worked with it day in and day out for the last seven years. I've come to learn its quirky ways, and for the most part I get by. I do warn my employers that putting your source code in VSS is akin to putting your life savings in a wet paper bag in the back alley, but most PHBs see that it's 'free' with MSDN, and that's the end of the topic.
Over the course of years, I've seen vss databases 'corrupt' themselves. This is often recoverable using analyze.exe, but not always. I schedule regular vss database maintenance to prevent this, and I've been fortunate enough lately that nothing has happened.
Until today.
We use CruiseControl.NET and nAnt to run our continuous integration builds. We get regular emails after checkin, and these usually assure developers that their code didn't 'break' the build. We do get the occasional 'Build Failed' email, but these are easily rectified with a quick turnaround. (Continuous Integration rocks!).
Today, I got a build failed email. Well, not just one. Twenty-Five 'Build Failed' emails. They weren't terribly clear, but obviously something major was wrong:
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: No VSS database (srcsafe.ini) found. Use the SSDIR environment variable or run netsetup. . Process command: C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE history $/polaris_Dev -R -Vd4/5/2005;2:22:44p~4/5/2005;2:52:52a -Yguest, -I-Y at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) [etc, etc]
The CC.NET stacktrace was more informative:
4/5/2005 3:37:38 PM: [polaris:Error]: Exception: Source control operation failed: File "\\vss\vss\Active\polaris_Dev\data\b\bvsaaaaa.a" not found
. Process command: C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE history $/polaris_Dev -R -Vd4/5/2005;3:37:34p~4/5/2005;3:36:28p -Yguest, -I-Y
--
Anyone who's spent time with VSS should dread the familiar \data\a\aaaaaaaa.a error message. This almost always points to database corruption.
We shut down our vss access immediately, and ran analyze on the database.
Analyze seems to have found the problem:
Writing a new copy of 'f:\vss databases\active\elink_dev\data\b\bvsaaaaa'.
But it unearthed another issue:
The file 'f:\vss databases\active\elink_dev\data\p\pjraaaaa' appears to be corrupt. Unable to read the format or header.
So far, I’ve not been successful in fixing the above error, and it’s vexing me.
Sometimes I feel like I'm sitting on a vss sinkhole. One day it's going to swallow all of our source code.
--
I wrote this for all of the people who say "I've never heard of a problem with VSS". I've had several over the course of the last half-decade, and each one is a significant cause of distress. Usually these problems manifest themselves in lost history, which many teams never notice because they don’t do historical builds. Sometimes they blow up the database, and you’ve got to pull out the backups. Neither scenario is fun, and I’d like to avoid them in the future.
Perhaps I should print out my source code and put it in the file cabinet next to me. That should keep my source safe.
Filed under: .NET