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?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-12-13 23:07:18 CET