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.

1. SS CHECKOUT $/library -R -GF -Ykorbyp,*foo_pwd#21
   This command recursively (-R) checks out the latest database version of all items in $/library and its subprojects and places them in their pre-ordained working folders by force (-GF temporarily sets the Force_Dir ini variable to Yes but I recommend you do so permanently).
2. SS GET $/library -R -VD2-2-2002 -GWR -Ykorbyp,*foo_pwd#21
   This command recursively gets all files by version date (-VD) and replaces the writable (-GWR) files that are already in the working folder (from step #1).
3. SS CHECKIN $/library -R -Ykorbyp,*foo_pwd#21.
   This command eplaces the latest database version of all files in the project with the files from their working folders.

Method #2, VSS Explorer Virtual Rollback.

1. Select the file in VSS Explorer.
2. Check out the file using the Check Out command on the SourceSafe menu.
3. On the Tools menu, click Show History to display the History Options dialog box.
4. Click OK to display the History of File dialog box.
5. Select a previous version of the file, then click Get.

The Get dialog box appears.

6. In the Get dialog box, click OK.

A message asking whether to replace the checked out file appears.

7. In reponse to the message, click Replace.
8. Click Close to quit the History of File dialog box.
9. Check the file back into VSS Explorer using the Check In command on the SourceSafe menu.