subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: Problem when config SVN to the root of a sub domain name
Date Fri, 25 Feb 2011 03:58:25 GMT

On Feb 24, 2011, at 07:10, 曹振华 wrote:

> I want to set '' as the root of a svn repository, so I use apache's <Location
/> directive to make all request to this sub domain forward to svn system, and It performs
well when just reading from web interface. But I got problem with commitment, The error log
shows below:
> [Thu Feb 24 20:09:22 2011] [error] [client] (20014)Internal error: Can't open
file '/usr/local/svn/repos/error/format': No such file or directory
> [Thu Feb 24 20:09:22 2011] [error] [client] Could not fetch resource information.
 [500, #0]
> [Thu Feb 24 20:09:22 2011] [error] [client] Could not open the requested SVN
filesystem  [500, #2]
> [Thu Feb 24 20:09:22 2011] [error] [client] Could not open the requested SVN
filesystem  [500, #2]
> --------------------------
> I then found Problems can be resolve if I use <Location /repos> directive, and
visit '' as the root of repository, could someone tell me why and what is
the  cause of this problem?

There are several possible issues when trying to use "<Location />" to serve repositories.
Using a different location like "<Location /repos>" works around these. If you don't
want to do that, then you'll have to tackle the issues. For example, some clients will request
paths that don't exist, like /favicon.ico and /robots.txt. What happens when they do? Does
it produce a lot of errors, such as the ones you see above? You may want to install Alias
directives for each of these possible URLs and do something better with them, either redirect
them to actual files, or make them generate a more immediate error that would not clog your

The error you've shown above says that someone or something is trying to access a repository
called "error". Presumably you do not have a repository by that name. Do you perhaps have
a global rule that is redirecting errors to such a URL? If so, make that rule not apply to
this virtual host.

View raw message