[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: multiple svn repositories on apache without a /svn/ path ?

From: Matthew Kerle <matthew.kerle_at_sra.com.au>
Date: 2006-11-09 00:54:09 CET

[amend]
Sorry, turns out my browser was looking at the cached version of the svn
parent, after a refresh the Collection of Repositories page came up.
However this didn't crash apache, so it appears that a GET request is
handled correctly, but a PROPFIND request isn't (resulting in the crash).

Matthew Kerle wrote:
> Thanks for your quick reply Ryan! You solved my main issue!
>
> Ryan Schmidt wrote:
>> On Nov 7, 2006, at 19:01, Matthew Kerle wrote:
>>
>>> Is there a way to host a collection of repositories from the root of
>>> a website (apache virtual host) without using a /svn/ (or other)
>>> context?
>>
>> First off: it should be possible. It's not recommended, but it should
>> be possible to make it work.
>>
>> The reason it's not recommended is that it causes problems with
>> /favicon.ico, /robots.txt, and other URLs which by de-facto standard
>> must be at the root of the URL space, only now they can't be if you
>> set up Subversion like this. Also, if you ever decide that you want
>> to use the XSLT styling for the browser view of these repositories
>> (with the SVNIndex directive), you'll need a place to put the XSLT
>> and CSS files, and if you map your entire namespace to Subversion
>> repositories, you either have to host the XSLT and CSS files on a
>> different virtual host with a different hostname, or you have to put
>> them in one of your repositories. The latter is however not such a
>> bad idea anyway.
> Thats ok, we're a small development group (< 10) and we've only
> recently moved to svn from source safe, so I don't think we'll be
> looking at setting up XSLT transforms etc for a while yet, the team is
> still adjusting to branching and merging...;-p Also as you say, it'd
> probably be good to keep those files in their own repo (really good
> idea actually!)
>>
>> [snip]
>>> I'd prefer to use a single location tag and the SVNParentPath directive
>>> instead, like this:
>>>
>>> NameVirtualHost *:80
>>> <VirtualHost *:80>
>>> DocumentRoot C:\svn
>>> ServerName svn
>>> <Location />
>>> DAV svn
>>> SVNListParentPath on
>>> SVNParentPath C:\SVN
>>> <LimitExcept GET PROPFIND OPTIONS REPORT>
>>> AuthType Basic
>>> AuthName "Subversion repositories"
>>> AuthUserFile C:\Apache\Apache2\passwd
>>> Require valid-user
>>> </LimitExcept>
>>> </Location>
>>> </VirtualHost>
>>>
>>>
>>> but I've run into some problems. When I setup the Virtual host
>>> I can browse the repo ok with Firefox, and if I go to a url lower than
>>> /trunk in the Tortoise repo browser it's fine (checkout,commit are ok),
>>> but when I try to browse the repo root I get a '301 Moved Permanently
>>> error on PROPFIND'.
>>>
>>> According to the faq this happens when the svn repo overlaps with an
>>> existing website or a file of the same name exists. The Server also
>>> hosts our wiki, but that has a completely different document root
>>> and when I try this I comment out all the other <Location>'s. There's
>>> also definitely no file/folders in the other web root that have the
>>> same name as the repositories, so I'm not sure whats happening.
>>
>> Your VirtualHost looks mostly reasonable to me. The only thing I'd
>> change is the DocumentRoot, which should definitely not be C:\svn,
>> since there are no files in that directory that you would ever want
>> Apache to serve out directly; you want everything in there to go
>> through mod_dav_svn, which is taken care of with the SVNParentPath
>> directive. Point the DocumentRoot at any other directory, even an
>> empty directory you've created somewhere. Possibly you can even leave
>> the entire DocumentRoot directive out in this case; I'm not sure.
> 100% right! I removed the DocumentRoot declaration and the 301 errors
> stopped straight away! I guess apache was getting confused between
> trying to serve the root itself or handing over to mod_dav_svn. It's
> now using the apache global doc root (C:\www) which is empty. The only
> caveat is that now I can't get the "Collection of Repositories" view
> from browsing the root, but this has solved my major issue, which was
> having to add a <Location> tag for each repository.
>>
>> I must admit I've also never understood the LimitExcept bit, and
>> could only suggest leaving that out to see if it makes any difference.
>>
>>
> It's just there so I can browse the source in FireFox without having
> to authenticate. If anything LimitExcept would make the repository
> more open.
>
> Funny thing, this may have been occuring before, but I've noticed now
> that if I type
> svn list http://svn/
> then on the server the apache service crashes and is automatically
> restarted (I can tell because I'm VNC'd in, and a box pops up
> informing me that "apache.exe has generated errors and will be closed
> by windows....".
>
> I find the following in the apache error log:
> [Thu Nov 09 09:54:49 2006] [notice] Parent: child process exited with
> status 3221225477 -- Restarting.
> [Thu Nov 09 09:54:49 2006] [notice] Apache/2.0.55 (Win32) DAV/2
> mod_jk/1.2.15 PHP/5.0.3 SVN/1.3.1 mod_auth_sspi/1.0.3 configured --
> resuming normal operations
> [Thu Nov 09 09:54:49 2006] [notice] Server built: Oct 9 2005 19:16:56
> [Thu Nov 09 09:54:49 2006] [notice] Parent: Created child process 976
> [Thu Nov 09 09:54:49 2006] [notice] Child 976: Child process is running
> [Thu Nov 09 09:54:49 2006] [notice] Child 976: Acquired the start mutex.
> [Thu Nov 09 09:54:49 2006] [notice] Child 976: Starting 250 worker
> threads.
>
> It looks like mod_dav_svn is crashing and taking apache with it. Does
> anyone know if this is a known bug with this version of svn (1.3.1)?
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 00:53:56 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.