On Feb 24, 2011, at 07:10, 曹振华 wrote: > I want to set 'svn.x.com' 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 1.1.1.1] (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 1.1.1.1] Could not fetch resource > information. [500, #0] > [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not open the > requested SVN filesystem [500, #2] > [Thu Feb 24 20:09:22 2011] [error] [client 1.1.1.1] Could not open the > requested SVN filesystem [500, #2] > > -------------------------- > I then found Problems can be resolve if I use <Location /repos> directive, > and visit 'svn.xxx.com/repos' 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 logs. 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.
