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.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.
Sorry, this blog does not support comments. Why not?
I used various blog hosting services since this blog was established in 2005, but unfortunately they turned out to be unreliable in the long term and comment threads were lost in unavoidable transitions. At this time I don't want to enable third-party services for comments since it has become obvious in recent years that these providers invariably monetize information about their visitors and users.
Please use the links in the page footer to get in touch with me. I'm available for conversations on Keybase, Matrix, Mastodon or Twitter, as well as via email.