I had a Subversion repository hosted on a Linux server that I wanted to migrate to a Windows server. I managed to do this, but it wasn’t all immediately intuitive, so I’m documenting the process here in case I need to do it again sometime, or someone else benefits from it. To begin with, I found the wonderful SVN 1-Click Setup, which promises to do the whole installation of SVN on Windows at the click of a button. I thought that would be a good thing and downloaded it (here).
The installation had three steps, each of which I was allowed to skip — in the end I used only one of the steps, the first one, where the main svn installation is done. I didn’t want to create any new repositories or install TortoiseSVN; apparently the package is focused on situations where people want to set up SVN as a version control system on one machine, as opposed to a server-based setup. I could most probably have used the “standard” distribution from the main Subversion site instead of the 1-Click package. This became even clearer a short while later, when I looked around for some kind of service or similar, that I assumed had been installed to actually make the SVN service available on the network. I found nothing, and so I got the two files SVNService.exe and SVNService.exe.config from here (make sure you have .NET 1.1 installed to use this, and be careful when downloading, because otherwise you’ll get one of the many intermediate pages from the web frontend at that download URL). I copied the two SVNService.exe* files into the SVN bin directory (by default that’s c:\Program Files\Subversion\bin) and edited SVNService.exe.config to configure the paths to my SVN installation and my repository, as well as the ListenHost. Then I used InstallUtil (comes with .NET) to install the service:
> c:\windows\microsoft\.net framework\v1.1.4322\installutil svnservice.exe
Now I started the service and tried to connect to it the same way I always used to do with my Linux installation - by navigating a web browser, and also the TortoiseSVN repository browser to http://winny:3690/work, where “winny” is the name of the Windows server and “work” is the name of the repository. This did not work at all, the only output I got in the web browser was this:
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
In the repository browser I got an error message instead:
Error * PROPFIND request failed on ‘/’ PROPFIND of ‘/’:
Could not read status line: connection was closed by server.
I decided there had to be something wrong, and I had a number of ideas what to do. Actually these ideas turned out to be useless because the problem was a completely different one, but I think the steps I made trying to solve the problem were good nevertheless. First, I updated my TortoiseSVN client. The version I had been using was very old (similar to the old Linux server), so I thought there might be some incompatibility there. No change. Then I read the manual to find out how to migrate a repository, on the chance that the file format from the Linux server might not be correct for Windows. I used svnadmin dump work > dumpfile on the Linux side, created a new repository on Windows and recreated the content with svnadmin load work < dumpfile. Nice, especially since one of the tools told me during the process that my Linux repository had a structure version from SVN 1.0 times — as I said, I guess this might have been a good thing. But it didn’t solve my problem.
Finally I found the revelation somewhere in the SVN docs, and completely by chance: I stumbled upon a URL that had svn:// as the protocol specifier, instead of the http:// prefix that I had been using. Well, I had only ever accessed my repository either locally or via Apache on Linux, so this was complete news to me… although it makes sense, of course. Anyway, I replaced my URL with svn://winny:3690/work, and all of a sudden everything started working perfectly.