Frans Bouma's says it's not Visual SourceSafe's fault!  I agree with the general premise that SourceSafe is a good tool for what it is intended for (small-medium projects).  However, I disagree with exclusive checkouts, and the 1GB limit is incorrect.

Frans states that only one person should be able to checkout a file out at any given time, and that checkout should be scheduled by management.  SourceSafe very easily operates in a shared checkout mode.  If your team size is 3 developers or less exclusive checkouts might not be a problem, but we had an initial team size of 5 and exclusive checkouts also prevents disconnected work at home (on a laptop, for example).  Disconnecting makes sure that SourceSafe does not try to inform the network database that it is checking out a file.  When you come back in to work and connect to the network, SourceSafe automatically runs a checkout on all files you modified.  Plus, once you get to 9 developers, shared checkouts on project files are a must.  For one year I had between 5 and 9 developers worked on 300,000+ lines of code and only had 1 instance of having to do a visual merge.  And that visual merge took about 10 minutes to resolve.  The best practice we had was to emulate the CVS model of integration.  After making changes and before checking-in, we would "get latest version" into our local files.  Then we would rebuild and make sure all unit tests passed.  No problems.

The SourceSafe documentation does not state any database size limit.  Microsoft recommends that, for general use, keep the database size under 3-5 GB.  Actual limitations are individual files cannot be larger than 2GB, there cannot be more than 4 billion files and folders, and no more than 32,767 versions of a single file.  As the SourceSafe administrator for our department (with as many as 20 concurrent users), I have managed multiple databases ranging from 1.5-2 GB in size without incident and without performance problems.  An 8 GB SourceSafe database, like Frans mentions, would undoubtedly be slow.  Plus it was on a slow old computer.  I do not know why the company decided to keep their most important intellectual property on the computer most likely to fail, but I am sure that he had nothing to do with it.

Of course, these only make SourceSafe look more appealing.  For the price (as long as you don't pay for it), SourceSafe is a good-enough buy.

For more Visual SourceSafe information:

• Microsoft Visual SourceSafe Best Practices - for SourceSafe administrators
• Team Development with VS.NET and Visual SourceSafe - the guide on developing in VS with SourceSafe
• Visual SourceSafe home page
• Visual SourceSafe FAQ - very comprehensive third-party faq
• Marc LaFleur's weblog - Marc has a good bit of version control here, here, and here