Garret Wilson wrote:
> My first attempt at opening up a subdirectory of a repository for public
> access failed failed. I was doing this:
> I changed the subdirectory designation to this, and things worked:
> 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
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 8 22:00:10 2005