VSS-to-Subversion Conversion


The motivation behind creating this page, and the provided Perl migration script, is that after scouring the Internet for a good VSS to Subversion migration tool, I came up empty handed.  That's not to say completely empty handed, but the only script I found (vss2svn.py) -- a Python script -- was too buggy to use.  After several failed attempts to 'fix' the vss2svn.py script, I finally gave up.  Not because vss2svn.py is beyond repair -- maybe it works for some people -- but in my case, it would get a dozen hours into the migration of our source control, and then fail.  At which point I would try to correct the error, and restart.  After several of these attempts -- and thus several days burned -- I decided it would be quicker to write one from scratch.  Was I right?  Was it quicker to write one from scratch?  It's hard to say.  This script took me about three days of fulltime effort to get going.

Scoping and Limitations

The provided migration script was designed to meet the needs of my company, and thus may not meet the needs of others.  Let me give you some insight into the decisions we made when cutting over from VSS to Subversion.
The requirement to generate historical builds (ie. precise builds of prior releases of our product) was examined and the decision made not to attempt that level of migration.  Why?  Principally because the build scripts that we wrote that ran against VSS would also have to be migrated to run against Subversion.  As this was a low frequency operation, the decision was made to 'deep freeze' VSS.  VSS would remain exactly as it was at the time of migration, and the 'old' build scripts and processes could be run against it to generate historical builds if needed. We also decided that moving 'deleted' material from VSS to Subversion was of little value.  As was migrating to Subversion all of the history of file and directory renaming.  These operations, especially the later, would have complicated this migration script significantly.
What does this mean for you?  What this means is, this migration script will take all live files in a VSS project and migrate them to Subversion.  Additionally, for those live files, all file history will be preserved.  Without this, it wouldn't be a migration, merely an import. 

With respect to file rename and move history, we take a simple approach.  Take this example:

A revision of a file resided in VSS under:

   /src/test/foobar.java (version 1.0)

and was later moved to 'newlocation' and subsequently edited:

  /src/newlocation/foobar.java (version 1.1, 1.2, etc.)

So, when these files are migrated to Subversion, the entire history of foobar.java appears in one location:

  /src/newlocation/foobar.java (version 1.0, 1.1, 1.2, etc.)


Running the Script

The migration script is written in Perl, and is designed explicitly to run in the Windows command shell.  I know, you want to run it in cygwin -- so did I -- but you can't so get over it.  The script makes a couple of assumptions:
VSS is visible from the machine the script will run on. Subversion is configured and visible from the machine the script will run on.

If you run the migration script with the --help option, you can get usage information:

E:\dev\>perl migrate.pl --help
Usage: migrate [options] project

Migrate a Visual SourceSafe project to Subversion.

  --restart             restart the migration from last checkpoint
  --ssrepo=<dir>        repository path, e.g. \\share\vss
  --sshome=<dir>        VSS installation directory
  --repos=<url>         URL for the Subversion repository
  --force-user=<user>   force the files to be checked into Subversion as
                        as user <user>
  --dumpusers           after pre-processing the VSS repository, create a
                        users.txt file which can be used to create comparable
                        accounts in Subversion.  The migration can be restarted
                        without penalty by using the --restart option

An example invocation is:

perl migrate.pl --ssrepo=\\server\vss_share --sshome="C:\Program Files\Microsoft Visual Studio\VSS\win32" --repos=http://linux3/svn $/project

In order to ensure that files histories are created in Subversion with the same username as the original creator in Visual SourceSafe, it is useful to first run the script with the --dumpusers option.  This will create a users.txt file after the repository pre-processing phase (but before the actual import into Subversion begins), which you can then use to create users in Subversion.  You may then re-run the migration script with the --restart option, which will attempt to skip over all the costly processing that was already perfomed.

Here is some example output:

Visual SourceSafe to Subversion Migration Tool.
Brett Wooldridge (brettw@riseup.com)

SourceSafe repository: \\devserver\vss
SourceSafe directory : C:\Program Files\Microsoft Visual Studio\VSS\win32
SourceSafe project   : $/Jakarta
Subversion repository: http://linux3/svn

Building directory hierarchy:   done (2754 dirs)
Building file list (100%):      done (9648 files)
Building file histories ( 45%): top_source.bmp


There are four primary phases in the migration run:

Building Directory Hierarchy
 Determines the directory structure of the project in VSS
Building File List Determines the list of all 'live' files in the VSS project
Building File Histories Determines all version information, time/data information, user information, and checkin comments for all files identified in step 2
Extract and Import Extracts files one-by-one, version-by-version, from VSS and checks them into Subversion

These phases get longer in duration due to the increasing volume of data being handled at each step.  As an indication of the kind of durations I'm taking about, the approximate times for migrating a 1000 directory project, with 6000 files, and 24000 versions were:

Phase 1: 20 seconds
Phase 2: 1 minute
Phase 3: 45 minutes
Phase 4: 13 hours

The migration script was run on a 2.3GHz Pentium 4 with 1G of RAM.  Not that RAM matters, as the script needs no more than 5MB or so.  I strongly suggest that you not migrate from the VSS root (/$) , but instead migrate on a project by project basis.  If you are brave, and try it, and it works on a large repository (say, one that takes 3 days to migrate), please let me know.  I'd love to know that this script could handle that without falling over.

This script was tested on our VSS 6.0 repository and Subversion 0.37.

This script is released for unrestricted use under the sole condition that any publicly available modifications are also sent to me via email.

You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser