Scott Nonnenberg asks why anyone still uses Visual SourceSafe (VSS), especially versus CVS, after some recent bad experiences with it. Here’s my take on the situation.
The nice part is that VSS actually integrates with VS.NET while CVS does not. For CVS, you have to install CVS or CVSNT, then grab TortoiseCVS for a GUI, and some other software (from commercial vendor PushOK ($19) or the open source SCC plugin for TortoiseCVS) to integrate with Visual Studio.
The reason why many developers still use VSS is because it provides all 3, a version control system, a GUI app, and Visual Studio integration, in one free package. Even though you can get all 3 parts via open source software and piece them together for free, people still pay lots of money for SourceGear's Vault because it already pieces it together for you. I expect to see open source software improve its integration with VS.NET now that the SCC API no longer requires an NDA.
I don't know what the environment that Scott was working on is like, other than the pre-Beta status had something to do with it, but I rarely run into data corruption issues working on teams of up to 10 developers. You do have to manage VSS and the server it resides on well, which may be a challenge to some people (I’ve seen it several times where the VSS database resides on the oldest, slowest, worst POS computer in the company, and they blame VSS for the problems!). But I'm still scared enough to move to CVS or Vault.
The downsides to VSS are that there are no atomic commits, the UI sucks, documentation is sparse, and it doesn’t work well over a distributed network (which is why Source OffSite from SourceGear does so well). And it doesn’t natively support secure communication; you have to setup IPSEC on the server (which you should do even, no especially, on your internal network at work/home!).