Migrating from Visual SourceSafe to Subversion

For years now, we've used Microsoft Visual SourceSafe (VSS) for our source code control, but given that Microsoft dropped support for it some time ago in favour of Team Foundation Server, we've decided to switch VSS with an open source system. This article describes our experiences with a test migration.

As I tend to prefer the client/server model I decided to trial Subversion (SVN) over other systems such as Git or Mercury. I also want to be able to import the VSS databases containing our current code, and the one with the legacy VB6 components we used to offer.

Installing SVN

As SVN is a client/server system, you will need to install both the SVN server and a client to connect to it. Or multiple clients depending on what integration options you need. For this migration test, I'll install everything locally, but for real use you'll want to install the server software and repositories on a server. You'll still need to install the client locally however.

As SVN is open source, there are multiple clients and servers out there - some free, some not so free.

Choosing a SVN Server

I don't have a lot of experience with SVN - I've used TortoiseSVN and AnkhSVN for client side. For the server, I choose to go with VisualSVN Server as it promised to be easy enough to install - and it is free (or at least the standard version is). And surprisingly enough, it was - a few simple clicks and the server was installed.

When you install, you'll be asked if you want to use HTTP or HTTPS - HTTPS will be more secure, but you'll need to verify (or replace) the default certificate or the migration tool will fail.

As our VSS user accounts mirror Windows users, I choose to enable the Windows authentication option. As this is the free version of VisualSVN, I have to use Basic (meaning you'll be prompted to enter credentials), if you want Integrated (where your Windows credentials are used automatically) you need to purchase the Enterprise license.

Creating a Repository

Next, I fired up VisualSVN Server Management console and created a repository ready for the migration. To do this, right click the Repositories node and choose Create New Repository from the context menu. Enter the name of your repository, and check the option if you want the default SVN structure created.

In the next section, you'll need the URL of the repository that you just created. If you didn't copy this from the Create dialog, right click the node for your repository, and choose Copy URL to Clipboard from the context menu.

Verifying the Certificate

If you configure VisualSVN Server to use HTTPS, it seems to automatically create a self-certified certificate. As it is not issued by a trusted authority however, you'll run into problems trying to actually use SVN. For example, running an SVN command will issue the following error:

Error validating certificate for '<servername>': 
The certificate is not issued by a trusted authority

And running the migration tool will offer this:

OPTIONS of '<repository>': Server certificate verification failed: 
issuer is not trusted (https://<servername>)

To work around this, we need to get SVN to permanently accept the certificate, which can be done from the command line.

• Open a new command session, and browse to the bin subfolder of your VisualSVN Server installation.
• Enter the command svn ls <repository> where <repository> is the URL of your repository.
• When the message is displayed informing you about the certificate, press p followed by enter to accept it.

This will allow you to use the command line tools, and will also prevent the migration tool discussed below from crashing when you try and use it.

Gaining Access to the Repository Folder

When VisualSVN was installed and it created a folder for storing repositories, it doesn't actually give access to that folder for the current user. This is something else that will cause the migration tool to fail. Using Windows 7, when trying to access the folder, you are both told you don't have permission and have a "one click" option to give you permission. For other operating systems, you will probably have to edit the folder permissions manually to grant yourself access.

Before performing the migration, ensure that you have access to the repositories folder.

Choosing a SVN Client

As mentioned above, the only SVN client I've used in the past was TortoiseSVN. I've no doubt that there are other clients out there (while VisualSVN does have a client, you do need to pay for it), but I decided to stick with this. As with the VisualSVN Server, installation is a breeze. Irritatingly, you are not able to change the installation directory.

Choosing a Visual Studio SCC Provider

TortoiseSVN is all well and good for managing from Windows Explorer, but that isn't quite good enough. I need support in the Visual Studio 2010 IDE, and for this I've gone with AnkhSVN. As with the other two products, installation of AnkhSVN was quick and painless.

Preparing SourceSafe for Migration

• Ensure all files are checked in.
• If you are using SourceSafe 6, install the final service pack for Visual Studio 6.
• If you are using SourceSafe 2005 (version 8), you may wish to install this patch from Microsoft.
• Run the analyze.exe tool to ensure your VSS database contains no errors.

Migrating a SourceSafe Database

As neither SVN nor VSS have appropriate import/export functionality, we need to turn to the community for help. Fortunately, there's a tool you can download from PowerAdmin. In addition to the original tool, there's also user supplied contributions - I went with Update 5, which is the latest at the time of writing and is supplied as C# source developed using Visual Studio 2008. While other versions using C++ are available, the remainder of this article discusses the C# version.

Setting Up the Migration

Before you run the migration, you need to configure a number of parameters. Open up the tool downloaded from the link above in Visual Studio - if you're using Visual Studio 2010, you'll be asked to upgrade the project.

The first thing you'll need to do if you are running a 64bit OS is to configure the project to be compiled as a 32bit application, otherwise the first thing you're going to get is a nasty COM error.

Next, open up app.config - there's lots of values in here to change.

• VSSDIR - name of the folder where your VSS database is located (the folder which contains srcsafe.ini)
• VSSPROJ - Name of the project to import. According to the tools documentation, you shouldn't specify the SourceSafe root, but instead the initial children. (Meaning if you have multiple projects at the root level, you'll have to run this tool multiple times.)
• VSSUSER - VSS login user name
• VSSPASSWORD - VSS login password
• SVNUSER - SVN login name
• SVNPASSWORD - SVN login password
• SVNURL - URL of your repository
• SVNPROJ - name of the SVN project to create
• SVNREVPROPSPATH - The local folder where your repository will be stored
• WORKDIR - Temporary directory where local files will be extracted. Make sure this folder actually exists before running the tool! In addition, the tool will create a folder named _migrate - make sure this folder doesn't exist or the tool will crash when trying to create folders if they exist.

With this information specified you're good to go - just run the solution. And go make a cup of tea, you'll be waiting a while, depending on the size of the database. I've tested with two databases, one 40MB and one 4GB - the former took an hour, the later 26 hours for a partial import.

Sadly, whilst the PowerAdmin migration tool supports comments, it doesn't seem to support labels, so if your database uses these they won't be present.

Verifying the Migration

On returning to the VisualSVN Server console, it wasn't showing the new projects - pressing F5 to refresh the list solved that, and I could see all the projects that had been imported. So far so good. Now time to check a file.

And this is where VisualSVN fell flat - it seems that you can only view the latest version of a file. So with that said, I opened Windows Explorer, right clicked the file list and chose TortoiseSVN | Repro-browser from the context menu. I then search for a file which I knew had been checked in numerous times, and was able to view its full history... even the dates were correct. Comparing a few random revisions of the file looked fine too.

I could see the initial comments from when the file was first added, but as I suspected no label comments were present.

The next thing to do would be to compare the full repository against the SourceSafe working copy.

To do this, I returned to the root project in the Repository Browser, right clicked it and choose Checkout. I entered a folder name (make sure this is something which doesn't already exist) and then checked out the entire trunk. After that was all checked out, I compared the two folders using WinMerge.

The comparison looked good - source code was identical, except for the Visual Studio project files - the migration tool automatically removes the VSS bindings from them which is a nice touch.

Once you open your solution, you need to tell Visual Studio to use AnkhSVN. To do this, open the Visual Studio Options dialog and select the Source Control | Plug-in Selection section. Simply select AnkhSVN from the dropdown list and you can then use SVN from within the Visual Studio IDE, in addition to Windows Explorer via TortoiseSVN.

Things That Can Go Wrong

Although the migration of our .NET code was successful, when testing with the database containing the old VB6 components we used to offer, the migration would crash for two different reasons:

The first was an occasional (and somewhat random) Access Denied when trying to commit files. Retrying the commit always worked, but it was at this point that I found the AUTORETRY setting isn't actually used. I manually updated the migration tool to retry commits in this case.

The second one would be the following error when trying to get a file from VSS.

SourceSafe was unable to finish writing a file. Check your available disk space, 
and ask the administrator to analyse your SourceSafe database.

This patch apparently has a fix for this, but I haven't tried it yet.

Once I have resolved these errors, I'll post an updated version of the migration tool. With workarounds in place, the migration still completed successfully so I'm cautiously optimistic for updating the tool and doing a true migration and switch.

Conclusion

It's still a little early for me to say whether we'll stick with SVN or try something else. While I never did like SourceSafe's habit of cluttering directories with .scc files, I am even less enamoured of the .svn directories and the additional disk space they take. But I'm sure of the fact that it's far less likely that a repository will be corrupt!

Another minor annoyance; we currently have Visual Studio set to check in each time the solution is closed. This functionality doesn't exist in AnkhSVN and so a manual commit will be required - there are arguments both for and against this type of functionality, I happen to prefer having the code constantly updated the central store, regardless of whether or not it actually builds.

The main problem is currently the loss of labels - tracking down the source code for a particular product build currently looks like a fairly large problem. It may be that the migration tool can be modified to support this, which I'll be looking into over the coming days.