I currently have an ageing subversion 1.4.2 server with multiple repos that I want to upgrade. I want to do a few things:
- Move to a more recent version (1.7+) of subversion
- Split the repositories to different machines
- Change the hostnames (I’ll explain this in a second)
- Change to use a FQDN rather than a path on the URL (<– This is the problem I have)
However, I want very little downtime and I want to do this progressively and (to a large extent) seamlessly to our users.
So, the server is currently resolved by: svn.svr.mycompany.co.uk
I want users to switch to using: svn.mycompanyglobal.net
That new name will be routed by DNS to an appropriate server depending on which continent the user is on. This works.
This points at an Apache2 install with svn DAV access of the standard type:
<VirtualHost 10.11.22.33>
Servername svn.svr.mycompany.co.uk
<Location /main>
DAV svn
SVNPath /home/svnrepo/main
[... Some regular auth stuff ...]
SVNIndexXSLT /svnindex.xsl
</Location>
<Location /data>
DAV svn
SVNPath /home/svnrepo/data
[... Some regular auth stuff ...]
SVNIndexXSLT /svnindex.xsl
</Location>
</VirtualHost>
There’s the usual stuff related to document roots and modules, but this is the crux of it.
So, at the moment I can check out code from: http://svn.svr.mycompany.co.uk/data/Core/Blah
Now I’ve put an nginx reverse proxy in front of this. It has the global host name and I can browse code via the URL: http://data.svn.mycompanyglobal.net/Core/Blah (Note that I’ve moved the “data” from the path to the name of the host). I’ve achieved this in nginx by adding the following configuration:
server {
listen 80;
server_name data.svn.mycompanyglobal.net;
proxy_set_header Host svn.svr.mycompany.co.uk;
location = /svnindex.xsl {
proxy_pass http://svn.svr.mycompany.co.uk/svnindex.xsl;
}
location /data/ {
proxy_pass http://svn.svr.mycompany.co.uk/data/;
}
location / {
proxy_pass http://svn.svr.mycompany.co.uk/;
rewrite ^(.*)$ /data$1 break;
}
}
This all works. I can browse the code in a web browser and via the repo browser in either TortoiseSVN or via the command line “svn ls”. All of this via the proxy.
However, when I try to check out the code I get the error
Unusable URI: it does not refer to this repository
I’ve come to the conclusion that this is the client making this decision (i.e. to raise the error). Looking at the SVNKit source code it is clear that the svn client compares the path it requested to the path that the server returned – I’m not sure why, but that’s what it looks like (see DavUtils).
I can solve this problem (sort of) by changing the URL I checkout from to this:
http://data.svn.mycompanyglobal.net/data
[ i.e. I add the name of the repository to the end ]
This probably works because of the “/data/” route I’ve added above.
Has anyone managed to do anything like this? Is there something I can do on either the Subversion server or the proxy which changes the presentation of the path to the subversion client?
I know that once I get this on to separate servers it will stop being a problem because each server will only have one “Location” listed (the root), but I don’t have the luxury of this at the moment.
Also, you should probably bear in mind that this box has been around for donkey’s years and there are a lot of hard-coded references to it. That’s why I need to proxy it so that I can progressively move all of the references to the new URL format.
I appreciate that this is a long question, but I hope I’ve made it clear what I want to achieve. Feel free to tell me I’m just insane – it just feels like I’m so close to getting it working :).
I might understand your context correctly. I’m sure you are aware of this but SVN also runs on different ports so you may have an issue there 🙂
With regards to the
locationparameter in nginx, you’ll have to keep in mind that it is only defining the location for the server name that you set in your config. So for the only server name above that you defined asdata.svn.company.comyou are defining each location for that subdomain. I think you are actually trying to define multiple subdomains.So if that is the case, you’ll have to set up multiple server names like
main.svn.company.comanddata.svn.company.cominstead of defining the location URI.Hope that helps 🙂