HumbabaSVN

Setting up Subversion

At last, I have elected to migrate my personal source control activities from Microsoft Visual SourceSafe (VSS) v6.0 to Subversion. Both systems operate against a system of flat files. VSS has worked well, even with the repository stored on a Linux server running Samba, but I used Windows very infrequently now. Most of my daily work is on a Linux workstation against a Linux server, doing *nix types of things. Since VSS is a Windows-based tool, I need to migrate to a tool that offers a *nix client. Subversion, with its long history and high regard in the community, has clients for many environments, including Windows. So, it makes sense to switch over.

2018-01-15 -- VSS dump

The first challenge was getting the VSS data out of VSS. I really, really wanted to retain the history of my projects, not wanting to start fresh with subversion. An internet search listed a number of tools for migration, some commercial projects, others freeware. I was interested in a tool that would specifically migrate from a VSS 6 setup to Subversion and I found two, unfortunately, both called vss2svn. The first I examined was rather tenuous. I wasn't sure if it was legitimate or not. It required a bunch of stuff, including VSS libraries, and ran on a Windows machine. The second I found was stand-alone, depending on no Microsoft materials other than the VSS repository itself. That one made sense to me!

It was a challenge though; the project is basically terminated, and the developers of the tools have moved on. They have a historical webpage with sources, which provide for a C-language-based EXE for extracting the data from the VSS repository, and a Perl-based tool for outputting a properly formatted SVN dump file that can be imported to Subversion. These two tools interoperate during execution, and they must both be present. I was able to prepare the Perl side of things without too much trouble, but the C source would not build for me.

At last, following up with further searching, I found the project's former home on code.google.com that offered prebuilt binaries. These were both Windows EXE files labeled version 1.11. I downloaded an extracted them, and fired up a Windows 7 machine, opened up a CMD window, mapped my old VSS repo to a temporary drive letter, and ran the tool. It went to work, and generated a lot of output. There were a number of warnings along the way, but what could I do? I had to accept what came out. That process took several minutes. When it was complete I had a file called vss2svn-dumpfile.dat which was just over 20MB in size.

Installing Subversion (1.16)

Humbaba is currently running Debian 6 "Squeeze". Using aptitude I installed the available subversion package, which is at version 1.16. All went smoothly with just a couple of dependencies also being installed.

I spent the next couple of days educating myself on subverison, finding an online book at the following link:

http://svnbook.red-bean.com/en/1.6

(there are also books for 1.7 and a draft in-process for 1.8 by changing the URL)

This book is a must-have because the manpages for svn are essentially empty, giving no useful information. A shame that.

With the online book I was able to learn how to create a repository and use it in a 'direct' fashion on the same host using the file:// URI scheme. Using a practice repository, I imported the vss2svn-dumpfile.dat.

# svnadmin create /var/lib/svn # svnadmin load /var/lib/svn < vss2svn-dumpfile.dat

This worked very well. The only unfortunate result is that in my VSS use time-frame I moved or renamed a number of projects and they came over under an 'orphan' top directory. Viewing the svn log shows that the project eventually was moved, and so checkouts and commits with the recent sources are fine. It'll work.

I set up the SVN server so I could take advantage of remote operations. This was easy, but required a few manual tweaks. First I installed the server as a inet server by adding the following to /etc/inetd.conf, and restarting the inetd server:

svn stream tcp nowait root /usr/bin/svnserve svnserve -i -r /var/lib/svn

I had to edit a couple of files for authentication:

/etc/subversion/servers with:

[global]
store-passwords = no

/var/lib/svn/conf/svnserve.conf with:

[general]
anon-access = none
password-db = passwd

[@/var/lib/svn/conf/passwd

with:

[users]
jared = <password>

That's it, I'm now up and running.