If you're like me, you don't necessarily label your
Visual SourceSafe* project folders as methodically or as often as you
should. My failure to do so recently found in me in a pickle. Here's what I did
and how I worked around it:
Over the course of three or four months, I built a simple ASP.NET
DataGrid library app for an extended team. I wrote it in C# using Visual Studio .NET
2003 * and added it to my favorite
VSS database before writing a single line of code (as I try to do
with all projects). My teammates can easily add their books to the online library. They
simply enter an ISBN, click Go, and boom, all other fields (author,
pubdate, pages, price, rating, etc) are autopopulated in the
DataGrid by a little menehune librarian in the
Web Services department over at Amazon. If you haven't
investigated the Amazon Web
services development kit yet, I recommend you do. But I digress.
One day, I decided to change my library's backend from
>>lib.xml<< to a slightly more manageable, secure, reliable,
redundant, and extensible data store: a SQL Server* database. Like most
adhoc coders with more desire than brains, I planned for a few seconds and then
started hacking at my aspx file. After two days, I found myself swimming
in version-mismatched files and broken build after broken build. My source
files were more comment than code, my task list looked like a Mozart symphony
put to words, and I was on the brink of a buffer overrun. I know
you've been there... hair in fists, chips on floor, pop or coffee on the wall,
mouse and keyboard dangling from your desk, monitor about to fall off its
stand--looking at you sideways like a disapproving parent. Yes, I was
ready to destroy my source files and START FRESH. And then a
little voice, a calm, quiet little voice--perhaps that of an Amazon
menehune--spoke to me from afar. 'C'mon dude, you work on the VSS team,' the
voice said. 'You know how to return your project to the last known
good version, even though you haven't kept check-in comments or maintained
labels as you should have!'
And I thought, 'Sure. I can do a Virtual Rollback (for lack of a better
term) in VSS, promote versions of all project files from a certain
date and time to the top of the version stack, and the next time I
check out, I can then rebuild the project as it worked two days ago when
everything was simple and XML was king.' So I did and here's how you can
do it if you ever find yourself in a similar situation:
Method #1, VSS Command Line, non-Destructive Rollback. This is
a little arcane, but some of the switch combinations I used have not been
documented very well.
Method #2, VSS Explorer Virtual Rollback.
The Get dialog box appears.
A message asking whether to replace the checked
out file appears.