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

Re: mod_dav_svn enhancement idea

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2005-05-08 14:19:50 CEST

Ben Collins-Sussman wrote:
> On May 7, 2005, at 9:49 PM, Michael Sinz wrote:
>> Would something like this be acceptable? Should I make some of the
>> fields optional? (Why or why not...)
> People have asked for improvements like this many times in the past,
> and our standard answer has been "no, please, don't go there."

I understand and that is why I asked. I have no real problem doing whst
I have been doing so far. I just thought it could reduce the server load
a bit by having some of the simple data directly available.

I do understand your point of view and have seen it on the list before.
No problem, and sorry if I bothered the list with the request again. It
just "looked so easy" when I looked at the code.

> WebDAV says that a GET request on a directory is "undefined", meaning
> we can do whatever we want. Instead of returning an error or a blank
> page, we decided to be a little bit nice and show a directory listing.

I may just use mod_rewrite to have the get on a directory go elsewhere...
It just makes the mod_authz situation a bit harder to deal with.


> Our standard reply is:
> * please, no more code bloat in mod_dav_svn.

Fully understand - I am a major "keep it simple, stupid" type of guy myself.

> * go install one of the many repository viewers instead.

;-) The reason I asked was to try to improve the Insurrection system a bit.

Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 14:20:39 2005

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

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