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

Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c

From: Lieven Govaerts <lgo_at_apache.org>
Date: Thu, 13 Dec 2012 23:18:37 +0100


On Thu, Dec 13, 2012 at 11:06 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 12/13/2012 05:48 AM, Justin Erenkrantz wrote:
>> On Wed, Dec 12, 2012 at 4:24 PM, C. Michael Pilato <cmpilato_at_collab.net
>> <mailto:cmpilato_at_collab.net>> wrote:
>> Here's a question I've been wondering for some time: should we expose to
>> users a configuration option for declaring the number of aux connections
>> ra_serf should use? I mean, Firefox has exposed such an option for years.
>> If we did so for Subversion, we could say, "Yeah, ra_serf+svnrdump is a bad
>> combination. Here's a workaround. Run it with
>> --config-option=servers:global:serf-max-connections=2". Or better yet (as
>> per my other mail in this thread), we could just hardcode that option
>> override in svnrdump itself.
>> Both approaches (allow config option to control # of conns; have svnrdump
>> disable parallelism) seems reasonable to me. FWIW, I'd probably set it to 8
>> - since 2006, most browsers upped their connection parallelism to 8. *grin*
> Okay. In r1421559 I implemented the http-max-connections option. Defaults
> to 4. Hard-coded limit of 8. (All that is up for discussion/debate/etc.)
> But on the way to adding the code to svnrdump to hard-code that
> configuration option, I found myself wondering ... could we get away with
> using a hardcoded-into-svnrdump *private* configuration variable that just
> means, "Do whatever you need to ensure that the editor is driven sanely"? I
> realize this is similar to the idea I previously shot down, but the
> difference here is that I'm not talking about using a user-visible,
> shows-up-in-the-config-template-file option here. Just a #define and a
> value stuffed into the configuration hash.
> Thoughts?

I have thought about the same thing before, but I don't think it's a
good idea. It will give our applications sort of an extra API that
external applications don't have.
But an application using the ra API might have the same problem with
ra_serf as svnrdump has.

IMHO, the option to make ra_serf respect a more stricter
interpretation of the editor api is something we need to give to a
developer, not to a user via config.

> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development

Received on 2012-12-13 23:19:31 CET

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.