On 12/13/2012 05:48 AM, Justin Erenkrantz wrote: > On Wed, Dec 12, 2012 at 4:24 PM, C. Michael Pilato <cmpil...@collab.net > <mailto:cmpil...@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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
