[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 13 Dec 2012 17:06:40 -0500

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.


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

Received on 2012-12-13 23:07:18 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.