This morning I've been trying to debug Subversion running under the Ark UI server. The architecture I've been using is:
What I've run into is that Subversion will redirect any directory URL that lacks a trailing slash to what it thinks is the correct URL with a trailing slash. However, the Subversion server does not know where it is hosted -- it thinks that the correct URL is the one that nginx passed to it, which has the "/svn" location stripped out.
These redirects are built into the Subversion code -- it's not configurable. See subversion/repos.c:1619 (or just search for "redirect" in that file).
These redirects do try to use the value of the Apache ServerName directive, but that cannot contain a path.
I've begun to think that Subversion cannot be run behind a reverse proxy with path-based routing, that it needs to be main public server, or it needs to be hosted at a subdomain.
However, see the following: http://silmor.de/proxysvn.php. This might point to a solution.
No, I don't think it does: It just amounts to adding a Destination header, but that doesn't overcome the issue.
I can manually set the ServerName in the svn apache config to
and the redirects will work, but that makes the server non-portable, and it doesn't solve the issue that the svn commandline has:
$ svn co http://localhost/svn/test1 svn: E235000: In file 'subversion/libsvn_client/util.c' line 96: assertion failed (svn_uri__is_ancestor(pathrev->repos_root_url, url)) Abort trap: 6
It's possible that Subversion can be hosted behind a reverse proxy, using path-based routing. I just don't see how at the moment. It really doesn't help that all the old subversion.tigris.org forums and mailing lists are gone.
Perhaps it's possible to ask a question about this on the Subversion mailing lists. They're still active, and the original developers should be there.
Otherwise, one solution for Ark would be to make the Apache Subversion server the main ark server, with the API sitting behind it, but the UI assets being served statically, and the /svn path being served directly.
I haven't addressed the issue of multitenancy yet with any of these solutions. This solution can work if every Ark account gets its own subdomain, running its own Ark server instance, which is authenticated via the main Ark identity service.