Last night
Last
night a coder saved my mind... Lutz Roeder, author of the awesome Reflector, saved me from certain
insanity. Here is how:
Yesterday I had my first really frightening
experience with SourceSafe. I can hear
the cries already, "But it's not
safe!" However, I have been using it for
years without serious or obviously inevitable incident, mostly because it's always
been what my employers have provided, as have many other people. For easily recoverable, small source trees
where versioning is not critical, and nearly everyone has a current working
copy, I don't think it is the Agent of Armageddon some would call it, but that's
where I stop. It's when things go a
little awry, when something out of the ordinary occurs, that SourceSafe comes
into its own as a truly destructive force.
When I work alone on small projects, I use
a separate, small SourceSafe database, for change tracking and backup, rather than
as a serious source code control tool. Just
as well. Like this, I can easily chalk
up ten to fifteen check-ins during the course of a day, just for a quick roll-back
facility if a refractor doesn't work, or I encounter a regression.
Last week on Thursday I began a serious
revision of an application I have developed and maintained over the last four
months. It's a small application, comprising
essentially a class library, and a trivial UI for testing the library. I have one class that controls export tasks
in the application, using discrete methods in another worker class to actually
perform the export tasks. For every
change to the control class, there would normally be about four or five changes
to the worker class. So, after a busy
weekend of furious coding, religiously checking in my project after every
change and good build, I noticed a little head icon on the worker class in Visual
Studio's Solution Explorer. It seems
that could mean a head rolling, mine or anyone else who is eaten up and crapped
out alive by SourceSafe.
I had been checking in and out, typing and
being prompted to check out checked in files, for four days. My control class version history shows
thirteen changes since Thursday, 26 July, so my worker class probably underwent
at least thirty, if not forty, changes in the same period. I will never be able to give you an accurate
number, because the version history for that class in SourceSafe ends on 11
July.
Here is where I admit fault, in that I have
never known SourceSafe to do bad things autonomously, although tales of mysteriously
corrupted databases are not hard to come by.
SourceSafe finally noticed something was up, and complained about
checking out the worker class file. It
said something about it being checked out by another user, so I opened up the
SourceSafe application, as integration with Visual Studio can be a little
problematic at times, and saw the file was checked out by myself. Nobody else has used the SourceSafe database
since March, and as I had so many small, incremental check-ins, I suspected no
real issue when I tried to check the file in, and SourceSafe complained
again. I decided to cancel the check-out
and, if necessary, redo the last ten or so minutes work. I had checked in before testing, and made
only minor adjustments after testing.
Imagine my horror when I opened the class
in Visual Studio and noticed code I had removed at the beginning of last
week. And it wasn't code I had put in at
the beginning of last week, it was code from months ago! I quickly viewed the history of the file,
hoping to get the previous version, and found the previous version, the last
check-in, was on 11 July. I thought
maybe SourceSafe had been referencing a file in another SourceSafe database, so
I check each one I had ever accessed, with no sign of my file!
With my heart on the floor under my chair,
at 10PM on Sunday night, I began resigning myself to redoing the all changes I
had made since 11 July. Then I realized I
could maybe disassemble the assembly for the project and salvage some of the
code, but I wasn't very hopeful, as I haven't released since last month, and the
only up to date assembly I had was in my bin\debug folder, and it may have been
overwritten with a compilation of the old worker class. Reason prevailed, and I realized the project
would not have compiled without error in that case, and my assembly would still
be OK.
I whipped out Lutz Roeder's Reflector and
disassembled the worker class. What an
absolute life saver! Almost everything
was replicated exactly as it had been when it was compiled into the assembly,
except for missing namespace qualifiers. I use a third party SDK, and all the fully qualified
type names from the SDK were reduced to only the class name, which required
some tweaking as some identical class names appear in two or three SDK namespaces,
but context these names appeared in, and compiler errors helped me sort that
quite quickly. I quickly did away with about
fifty initial compiler errors, with lots of search and replace and copy and
paste, and I was back in business.
I posted a quick rant about the experience on
CodeProject, and quickly drew quite a few sympathetic replies, the majority of
which convinced me to get as far away from SourceSafe as quickly as possible. My
thread even made it into CodeProject's Insider newsletter for today. Here are some of the responses:
"Yup. Surely, one of the great mysteries of
the Universe is whether or not Reflector's greatness is matched by VSS's
suckage." - Shog9, creator of the phenomenal CPhog GreaseMonkey
script for CodeProject forums.
"I will never, ever, use SourceSafe." - Marc Clifton, CodeProject MVP and author
of 115 articles.
"This is why we stopped using SourceSafe.
Personally I consider the product too dangerous to use. I'm astounded it's so
crappy. - Microsoft: You have billions and billions of dollars. Buy a company that has a
decent source control product." - Chris Maunder,
a co-founder of and the man who wrote CodeProject.