Here's the fun fact:
I've created a new repository 'toolbox_test' and loaded dump file into
it.
Checkouts/commits/updates AND merge works just fine.
There is no VirtualHost setup for toolbox and it's not accessable via
any URI.
I've added "DocumentRoot" to the configuration and that looks like it
solved the problem.
Thank you Stefan and Ryan for the help!
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2009b_at_ryandesign.com]
Sent: Monday, July 13, 2009 3:37 PM
To: Stefan Sperling
Cc: Sholokhov, Vitaliy; users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3
On Jul 13, 2009, at 12:33, Stefan Sperling wrote:
> What happens if you use an intermittent
You mean intermediate?
> directory as the repository
> location, such as "<Location /svn/>" and run
>
> svn switch --relocate http://crossbow:81/toolbox/branches/vitaliy \
> http://crossbow:81/svn/toolbox/branches/vitaliy
>
> in the working copies?
>
> The FAQ entry I pointed to earlier says:
>
> "The solution is to make sure your repository <Location> does not
> overlap
> or live within any areas already exported as normal web shares."
>
> I'm not sure, but I guess a location of / would pretty much overlap
> with everything else?
That's not exactly what that means.
Consider that you have a virtual host:
<VirtualHost *:80>
ServerName server
DocumentRoot /path/to/documentroot
<Location />
DAV svn
SVNParentPath /path/to/repositories
</Location>
</VirtualHost>
Imagine that there is a repository at /path/to/repositories/foo but
there is also a directory at /path/to/documentroot/foo. What happens if
you request http://server/foo/? Which of the two entities will be
reached? It's undefined. Apache might choose the one or the other, even
changing its mind depending on the circumstances. That is the situation
described in the FAQ, and is why you should not have things in your
document root that match the things you want to serve with Subversion.
In Vitaliy's case he intends to have a VirtualHost that does nothing but
Subversion:
>> <VirtualHost 10.2.8.10:81>
>> ServerName crossbow
>> <Location />
>> DAV svn
>> SVNParentPath /usr/local/subversion
>> AllowOverride All
>> # how to authenticate a user
>> AuthType Basic
>> AuthName "Subversion Repository"
>> AuthUserFile /var/www/.sub_passwd
>> AuthzSVNAccessFile /var/www/authz
>> Require valid-user
>> </Location>
>> </VirtualHost>
But no DocumentRoot has been defined in this VirtualHost, therefore the
server's global DocumentRoot is being used. Does that document root have
a directory "toolbox" in it? If so that could cause the issue. The
solution, and one you should employ in any case, is to define in this
VirtualHost a DocumentRoot, for example pointing to an empty directory:
<VirtualHost>
DocumentRoot /var/empty
<Location />
...
</Location>
</VirtualHost>
If that does not help, you may still want to move your repositories into
a subdirectory of the URL space (e.g. <Location /svn/> as suggested by
Stefan). There seem to be some edge cases when serving repositories out
of the root of the URL space which Subversion does not handle properly
in all configurations, and you will avoid these by serving out of a
subdirectory. This can also help you by giving you a place (e.g. your
DocumentRoot) for files that don't necessarily go in a repository, such
as favicon.ico, robots.txt, svnindex.xslt, etc.
******************************************************************************
Nothing contained in this e-mail shall (a) be considered a legally binding agreement, amendment or modification of any agreement with Marvel, each of which requires a fully executed agreement to be received by Marvel or (b) be deemed approval of any product, packaging, advertising or promotion material, which may only come from Marvel's Legal Department.
******************************************************************************
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2371097
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-13 22:03:05 CEST