Visual Source Safe to Subversion Conversion

Visual Source Safe to Subversion Conversion

by JBrooks 24. February 2009 11:12
Our experience with the Visual Source Safe to Subversion conversion.

Visual Source Safe
In general Visual Source Safe is known to have problems when the database gets large, if there are a lot of users, or if it is used over a network.

On Microsoft’s site they have the following warnings:

Many factors can cause a SourceSafe database to become corrupted. These factors include the following:
•    Power loss
•    System hangs (stops responding)
•    User terminates a long process
•    Bad network connections
•    Running out of disk space
•    Network problems
•    Operating system problems

Visual Source Safe Best Practices and Our Database:

1. Best Practice: Visual SourceSafe database should not exceed 3 to 5 GB    
Our Database: The VSS database that our source code is in is currently 25 GB.  

2. Best Practice: Use the Analyze tool shipped with Visual SourceSafe to detect and repair problems in the database structure… you can discover small problems and fix them before they become worse.   You should run it as frequently as is practical—once a week is recommended, or at a minimum, once a month.
Our Database: Analyze hasn’t been run on our database since 2004 (if ever).
During the VSS to Subversion conversion Analyze was run on a copy of the VSS database and it showed many files had corruption in their history.  We could never get it to run completely on the full copy of the database – we had to delete large sections and then run Analyze.
3. Best Practice:  Limit the number of users to increase performance and limit corruption.
Our Database:  Our files are in a single VSS database that is also used by many other groups.  It currently has 198 users defined and over 50 are still active.

After We Moved to a Remote Site - Our Servers are Now 2 Miles Away.
Each of the causes of corruption listed on the Microsoft site were much more likely to occur given the new environment that we were now in after moving to the remote site.

Here is what we were experiencing when we moved to the remote site.:
1.    When opening a project in VSS we would consistently get “Error reading from file” messages.
2.    A one minute “get latest” operation would now take over 20 minutes.
3.    Adding files to VSS over the network from the remote site would fail.


Many different solutions were evaluated including AccuRev, CA – AllFusion Harvest, Microsoft Visual Studio Team System, Perforce, CVS, ClearCase, SourceGear, AnthillPro and others.   It is outside of the scope of this post to review the details of this evaluation, but it is worth mentioning that the final two contenders were Microsoft Visual Studio Team System and Subversion.

After the addition of some other supporting tools, nothing fit our requirements and environment as well as Subversion.  It is open source, one member of our team had used it in the past and some other areas in our company have been using it for a long time.

For a quick background on Subversion and a list of features, start with this link:

If someone wants to do more research this link is a good starting point:


We placed the requirement on ourselves that in converting from VSS to SVN all of the history of all of our files must be moved to SVN, not just the latest versions.  Had this not been a requirement then the conversion would have been little more than doing a “get latest” on VSS and then importing this to a SVN repository.

So we looked at a few tools that would convert all of the history.  None of them allowed you to take an archive of only the VSS directories that you were interested in and perform the conversion on that.  (VSS does something funny internally with the dates on archiving.)    So the conversion had to be done on a copy of the VSS (25 GB) database.

All of the conversion tools also required the source VSS database be clean of corruption before the conversion.  This turned out to be much harder and time consuming than you might think.  Running the VSS Analyze tool on a copy of the database showed hundreds of corruptions and would not run to completion without blue screening the computer it was running on.

To get around this we reduced the copy database by deleting the directories that we didn’t want to convert.  Unfortunately VSS will report each corruptions during the deleting process causing hundreds of message boxes that the user must mindlessly click for the process to continue.

Once that point was reached, we used the tool VSS2SVN to create dump files that were imported into Subversion.

Our current environment consists of the following:
1. Subversion (SVN)  - source code repository (FSFS file format).  
2. Apache for Windows 2.2.9 – Subversion server.
3. TortoiseSVN - Windows client to Subversion.
4. AnkhSvn - Visual Studio plug-in.  
5. SharpSvn - library used for coding our own tools that work with Subversion.  (Example is a tool called “MakeRelease.exe” that reads a list of file names, opens those files from Subversion, and combines all of them into a big SQL file for a release.)


There was a learning curve that the developers had to go through after the conversion to Subversion.  This was driven by the different versioning models.  VSS has the Lock-Update-Unlock model of source control that does not allow for concurrent updates of a single file by multiple developers.    

In Subversion’s versioning model no files are exclusively locked (unless forced) and multiple developers can work on a single file at the same time. Once changes are completed, conflicts are identified and said developers manually merge their changes before a commit is allowed.  If there are no conflicts, updates are automatically merged.


Here is a quick introduction to Subversion (SVN) that compares it to VSS:

Here is a quick video showing you basic usage:

Here is another link that show the details of using TortoiseSVN

And a link talking about using SVN with Visual Studio:

This is SVN’s home page:

This is TortoiseSVN home page:

Free Subversion book online, very complete.

How to install Subversion with Apache server.

Vss2Svn conversion program:



Comments (4) -

african mango
african mango United States
7/5/2011 10:57:47 PM #

Thank you very much for the info.  What theme is this i really like it wish you would share with me where you got it if you can send me answer to email provided.

JBrooks United States
7/6/2011 7:46:13 AM #

There is a link to the Theme at the bottom of this page!

sumguy United States
1/12/2012 6:49:12 AM #

How long did it take to convert 25gb of data from vss to svn? Planning to do something similar and wondering about the amount of time to set aside.

jbrooks United States
1/12/2012 8:22:08 AM #

Because of the corruption messages required you had to click a button on each one as it came up - it took the better part of a weekend.