Caffeinated Coder

We’ve almost completed our first week on Subversion and all is well. Here are a few pieces of advice to those of you about to embark on a VSS to SVN migration of your own.

1. Spend Time Getting Buy-In from all Developers BEFORE the Migration – Force feeding a new tool to your co-workers is a recipe for disaster. Developers who aren’t given any input or choice in the matter may be compliant at first but will likely turn passive-aggressive on you at the first sign of trouble. We did some lunch-and-learns and focused specifically on current source control related problems that would be solved by migrating to a new tool well before we did the actual migration. This made life much easier during the inevitable bumps that came up during the first few days after the migration.
2. Be Aware of Tool Limitations When Migrating History – Unfortunately there don’t seem to be very many good options out there when it comes to migrating VSS history. After some failed attempts at using VSS2SVN and SVNImporter, I settled on using Eric Lane’s version of VSSMigrate. It accurately converted all the files in a 5GB VSS database, preserved history from the perspective of a single file, and stripped the VSS bindings from the project and solution files. The utility is also written in C# and the source code is provided so you can make tweaks as needed (I changed it to put the associated version label in the comment of the revision). Unfortunately, it doesn’t convert labels and more importantly it doesn’t preserve history from a holistic perspective since it loops through and commits the version history of one file at a time. If you really only care about doing diffs and not about reconstructing your apps as of a certain point in time, then I would recommend using this tool. Otherwise, keep looking.
3. Do Several Practice Migrations – I set up a Virtual Machine that mirrored our source control server and not only went through the migration several times on a copy of the full VSS database, but also documented each step to make life easier during the actual migration, which took place over the weekend when I was less…focused.
4. Don’t Forget About Dependencies – We had quite a few Nant, CruiseControl, and VisualBuild scripts that needed to be modified, which added quite a bit of time and effort to the migration process. A VM definitely came in handy when testing these changes as well.
5. Run VSSAnalyze Before Migration – Corrupted VSS chains are common and will likely cause havoc with a migration tool unless you try to fix them prior to the migration. Even after running Analyze, the VSS equivalent of duct tape, there were still 2 files with corrupted version history that I had to remove from the VSS database prior to the migration and manually add to SVN after the migration.
6. Use BeyondCompare to Verify Migration – Make sure that you do a full comparison of working directories from the new SVN repository and old VSS repository. Before performing the comparison, you’ll want to configure exclusions for the svn and vss specific files as well as the project and solution files if they have been stripped of bindings either by the migration tool or manually.
7. Open Up and Compile All Solutions After Migration – I discovered a resource file that somehow got dropped during the migration because one of the solutions would no longer compile.
8. Use SharpSVN to Extend and Script For SVN – I was surprised at how easy it was to create a pre-commit hook for SVN that would analyze commits and prevent the ones that didn’t contain a valid issue for our issue tracker (JIRA). This was partially because I used SharpSVN, an open source API, and was thus able to interact with the repository without having to parse command line return values from SvnLook.
9. Practice Backups and Restores Before Migration – Resist the temptation to put this off until after the migration and make sure you fully test any scripts that you use, especially if you don’t use the recommended Python scripts that can be found on the official SVN site . I couldn’t convince the Powers-That-Be to let me install a Python interpreter on our server, so I went surfing for PowerShell scripts and the first one I tried for incremental backups only actually saved the latest revision instead of the latest range of revisions. I didn’t discover until doing some testing on a practice restore that I did.
10. Plan the Migration over a Weekend – Most of the processes are very long running. The one that migrated our VSS history took almost 10 hours for a 5 GB database and we ran into some problems with our build scripts that took much of the day Sunday to debug.

Happy Migration!

Popularity: 27% [?]

 Subscribe in a reader