I'm currently working in an environment that still has VSS 2005. I currently do not have the power to change to Subversion, TFS, etc.
What are the main gotchas to watch out for with VSS 2005--how can I best use it to try and save my versions and not blow up my source code? For example, is it better to integrate it with Visual Studio 2008, or just use the VSS client?
I've had nothing but negative experiences with trying to integrate VSS with VS, so I would recommend not doing that. However, we were dealing with ASP.Net 1.1 projects at the time, which didn't have the nice feature of being able to live anywhere in any sort of folder structure, and that's mainly where we were running into problems - trying to sync the project structure with the VSS repository.
Other than that, I can only suggest that you don't check in code over a VPN connection that's prone to dropping. In fact... I would suggest never checking in code remotely at all ;) If the connection drops in the middle of a commit, you can double-down on whether the database just corrupted.
The last time I tried it (which was a long time ago), Visual Studio integration played badly with using VSS project branches.
I just use the VSS client.
Other recommendations:
Don't do anything complicated with VSS. I think many people who've never had problems with VSS were just using it as file share (i.e. files get checked in once and are never modified)-- ironically using VSS as ordinary file backup actually increases the odds of catastrophic loss!
VSS drowns you in a barrage of poorly worded questions. There is not a single answer to each question, you will have to stop and think about each one. When disconnecting from VSS you'll be constantly asked if you want to switch to using VSS over IIS, if you do so, it will not be obvious how to undo it.
Don't use the VSS plug in to get an initial project or check out a project. The VSS plug in tends to put your files in unexpected places, use the VSS client, which is much more likely to give you a folder structure that mirrors the project structure in VSS.
Don't use build in features to branch, don't merge. Create a new VSS project (i.e. new set of folders) and check in code as if it was a brand new thing when you need to branch. Use something like beyond compare if you need to simulate a merge.
Don't rename files, instead add new, copy paste, then delete. This breaks the history chain but has fewer aggravations
Do allow multiple checkout, but informally don't let too many much work be done on the same area of code, don't let other developers let their version get too stale because then you're trying to merge your old working folder version and the latest version and VSS tends to drown junior developers in questions they don't understand.
Don't do extremely large check ins. Don't use on a slow network connection without 3rd party products.
If you use the VSS plug in in visual studio, do periodically use the VSS client to compare and synchronize your working folder, but do so file by file, not in a batch.
Don't let the repository get too big. Split repositories for unrelated work.
Don't be fooled by the logon password. VSS is no more secure than the NTFS permissions on the folder.
When a developer leaves the company, ask them to undo their checkouts. It is an order of magnitude easier to undo checkouts using the same machine and user credentials and working folder than to use the admin account to undo someone else's check outs.
All best practices for any source control system also apply, e.g. check in successive versions of binaries as binaryfile.bin, not binaryfilev1.bin, binaryfilev2.bin, but do tell VSS that .bin or what have you means binary or it will try to do text merges.
How to live with Visual Source Safe 2005?
Alcohol. Loads of it.
Run a stealth SVN repository with an automatic job that checks out latest VSS files every night and checks them into SVN.
When VSS dies (and it will) tell the boss we have a second repository ready to go.