Garret Wilson wrote:
> Everyone,
> 
> My first attempt at opening up a subdirectory of a repository for public 
> access failed failed. I was doing this:
> 
> [repos:/]
> @mygroup=rw
> 
> [repos:/public/]
> @mygroup=rw
> *=r
> 
> I changed the subdirectory designation to this, and things worked:
> 
> [repos:/public]
> 
> I'm wondering why the decision was made to have a path not ending with 
> slash designate a collection (i.e. directory), but to have Subversion 
> not recognize a path ending in a slash?
The decission was quite simple, it made it work as easily as possible.
mod_authz_svn doesn't have access to the repository; it doesn't open it.
Therefor mod_authz_svn doesn't know whether a URI is for a collection or
not.
> According to general URI convention and the WebDAV specification, along 
> with several later community discussions, the canonical way to represent 
> a collection is with an ending slash. Technically, there could be two 
> distinct resources, /public and /public/, only the latter of which is a 
> collection. (The former could be a text file, for instance.)
> 
> (In fact, this relates to the reason we have to put BrowserMatch 
> "Microsoft Data Access Internet Publishing Provider" redirect-carefully 
> in our Apache config files:
Well, technically it's already in the default httpd config isn't it? :)
> Microsoft WebFolders won't correctly 
> redirect from /repos to /repos/ (and to make matters worse converts 
> user-entered /repos/ to /repos), meaning we have to tell mod_dav to 
> simply give /repos/ when asked for /repos instead of redirecting for Web 
> Folder clients. But I digress.)
 
> The Subversion convention of no trailing slash is also inconsistent with 
> its method of designating a repository root directory. (Consistency 
> would call for using [repos:] as the root designation.)
Yes, but [] looks somewhat wrong doesn't it?  I wonder if it would even count
as a valid config section name.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul  8 22:00:10 2005