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