VSS is great evaluation-ware (better than demo-ware). After using it for half an hour, you'll be convinced that it does everything you need. After you've made the commitment, you'll discover otherwise.
VSS uses an extremely chatty protocol (good old DCOM), so I find VSS unusable offsite. Latency is terrible. Over ISDN, it takes five minutes to navigate to the proper subfolder, check out a file, and check back in a modified version. Many at my office buy the third-party Source Offsite: their proxy translates into a more sensible protocol for their own client.
You'll also need a third-party client if you want to build your code on anything but Windows(TM). We must build on NT, Linux, and Solaris, so all our Unix synchronization was scripted by hand, to selectively update from Samba mounted drives. In effect, we've built our own source-control system alongside VSS.
We've found that the only safe way to synchronize a working copy of a VSS directory is to delete the entire branch of the tree and get a fresh copy. Otherwise, you'll never notice what files others have deleted or what new files you've forgotten to add to the tree. We've had the build break five days in a row for this very reason. When I check out files, I make a mirror copy of the directory under RCS, then use scripts to update VSS. My VSS tree is constantly deleted and refreshed to ensure real synchronization with the rest of the team.
The problem would be alleviated by changing "working folders" except that working folders do not work in any rational way. You'd like to switch between your polluted copy of a tree and a clean copy to check that your changes are compatible with others' more recent changes. You find that when you switch the working folder at the root of a tree, some sub-folders (sub-directories) remain with the old tree if files are checked out. You then discover that, by default, the same file will check out into one working folder and check in from another working folder. Yet time stamps and diffs make you think you checked in from the folder you put the file into and modified. Only when you delete and get a fresh copy of the tree, do you discover that you checked in the wrong version. To undo the damage, you must visit and reset every directory in the tree. You'll never try to change working folders again. (Everyone on the team tried it once and regretted it.)
Visual Source Safe provides no support for cross-platform text files. Extra carriage returns are inevitably introduced before line feeds in files created on Windows platforms. You will find it necessary to remove these carriage returns and check in the file in binary mode, so that the files can be used on other platforms. (Windows provides no tools for removing the carriage returns.) Unfortunately, VSS often decides that different white-space does not qualify as a change, and silently ignores the update. You must make a change to non-whitespace as well.
The database is appallingly easy to corrupt. On average VSS databases at our office corrupt themselves every week. One symptom is that directories appear in the wrong place as mirrors of other directories. Branches are not allowed until corruption is resolved. The database must be repaired with the command-line tool Analyze. First back up everything and disconnect all users.
I've used both CVS and Clearcase heavily and prefer either.
Bill Harlan, 2001
Return to parent directory.