What's the best way to persuade my employer to move from VSS to Subversion?

Question

My employer uses Visual Source Safe for version control, there are many problems with it's implementation, from the fact it's partly used as a document repository, to the problem that some repositories are approaching 20gb.

I want to move the company onto Subversion but I'm having problems finding concrete statistics of why it's better, or a justified list of why VSS is not a good solution, at least in the way that management would understand it.

So my questions are:

1. Can anyone provide me with some concrete reasons why subversion is a better system?

2. What are the offical limitations of VSS?

3. Any good ideas of ways I can put these concepts across in business terms?

Answer 1

I didn't have to do any persuading. Once VSS crashed, taking the whole database with it for the third time in 6 months, they were really ready to try something different.

Answer 2

Have a look at this question, which already has some good answers to your first and third questions.

Answer 3

Check out this article on VSS.

Answer 4

I did exactly this for a company a few years ago, now I wish I still had the stuff I wrote! Some quick things:

• Microsoft does not recommend repository size greater than about 4 GB.
• TortoiseSVN supports diffing (but unfortunately not merging) Word documents.
• The repository format in VSS is fragile and relies on proper client behaviour. Subversion is a server-based system and does not rely on client necessarily operating properly (this includes things out of the client's control like unexpected network disconnections).
• Subversion is far more performant when used across a slow link such as a WAN.

Of course, Jeff's article Source Control: Anything But SourceSafe is a good read on this topic.

Answer 5

• VSS promotes an ancient and outdated way of managing source control that has been replaced by nearly every modern platform.
• The UI [in Tortoise] is ridiculously easier to use. Even non-programmers can use it.
• Access repo's over http, remotely.
• Corruption. If the database becomes corrupted, there goes your repo.
• Microsoft doesn't even use it internally.
• I don't know if there is a realistic hard limit, but MS recommends keeping the db below 5 GB.
• SVN has a pretty rad API. I built a cool report generator with it.

Answer 6

If VSS is used as a document repository, chances are that there are not enough licenses for it. Typically all developers are covered because of MSDN licenses, but if non-developers are using it, they may not be covered. This could be costly if a disgruntled employee turned them into MS. The savings here would be preventative in nature.

Also, you can make the case: VSS does not support WAN access, so if you have any remote offices, or salesmen who need to access documents remotely, then it will be horribly unuseable. The cost to the company is lost productivity across a WAN.

Also, you can make the case that as the VSS DB site grows, the chances of database corruption increase significantly. The risk of at least some versions of the documents is almost a certainty. Cost: however much the document is worth.

Also, you can make the case that VSS, as a file access version control could be harmed / destroyed by a malicious person with access to the network. All they have to do is map to the folder the VSS repository is in, and start selectively deleting files.

Answer 7

Spam everyone with this link: http://www.highprogrammer.com/alan/windev/sourcesafe.html

Answer 8

VSS does not like unicode code files, and because VSS uses a diff-based versioning system, a unicode corruption can end up corrupting all versions of a particular file (even versions from before the unicode was added) all the way back to the original add-in. This happened to me. It sucked.

Tell your employer that keeping your code in VSS is like keeping all your money in your car: you'll probably be OK.

Answer 9

VSS does not do atomic commits, so an interrupted commit can leave some files matching your local copy and some files not. Subversion does atomic commits, so either it all goes or it all doesn't.

Network problems can interfere with commits, of course, but they can also interfere with checkouts. I spent many hours troubleshooting broken builds only to find that a checkout did not actually get the proper version of a particular file. Repeating the checkout (often several times) eventually fixed it, though sometimes it required doing a clean checkout (delete the previous local copy entirely).

Yuck!

I love Subversion and have used it for years, but I plan to move to Bazaar.