Have you considered creating a second URL for the same repository and block access to those directories that folks should not have access to with-in your Subversion authorization file?
You can see how to do this at:
Hope this helps,
>>> On Tue, Dec 4, 2007 at 1:03 PM, in message
<4755A49F.email@example.com>, John Aldridge
> We run Apache as a web server for internal company material. One of the
> things it serves is a URL
> which is currently an ordinary folder in the Apache DocumentRoot folder
> whose contents (mostly html files) are populated by checking out the
> "trunk/Documents" subtree of our repository.
> This has two disadvantages:
> a) Anyone who updates a document needs to remember to do an "svn update"
> in order to make the updated document visible, and
> b) It's a waste of disk (& backup tape) space.
> I wondered whether mod_dav_svn could be used to solve both of these
> problems by having Apache serve a direct view onto the repository, so I
> loaded the mod_dav and mod_dav_svn modules and added
> <Location /Documents>
> DAV svn
> SVNPath d:/svn-repos
> to the Apache config file. This worked, kind of, but has a number of
> problems which make it less than ideal
> a) I can't find a way of making the URL http://www/Documents show the
> contents of just "/trunk/Documents", rather than the repository root
> folder. This will break any existing links on other pages. The nearest I
> have to a solution is to serve the entire repository as /svn and add a
> Redirect /Documents http://www/svn/trunk/Documents
> directive. This isn't ideal, though, as I'd rather preserve the myth
> that these documents really do live in /Documents.
> b) I have no wish to allow write access to the repository via Apache
> (that's done by a service running svnserve). Is there a simple way of
> configuring mod_dav_svn to be readonly, short of configuring
> authentication and access control options.
> c) $Revision$ and $Date$ keywords are not expanded in the displayed
> documents. Not a critical deficiency, but a pity.
> I'd welcome any hints for solving these problems, or suggestions for a
> better way to solve the underlying problem.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Dec 4 21:10:40 2007