On 12/12/2012 04:04 PM, Lieven Govaerts wrote: > Note that send-all is not the solution if the server insists on skelta > mode (see my previous comment), so if you do an update or a checkout, > you still have to tell serf to limit to one connection.
And that's trickier than it seems, IIRC, because Ivan changed ra_serf to recycle even the first connection as an auxiliary one once the REPORT is completely processed. >> svnrdump is only trying to do essentally that anyway -- a update of >> ${NOTHING} to ${SOME_REV}. It calls svn_ra_do_update(), uses the provided >> reporter to say "I've got nothing", then finalizes the report and away she >> goes. Would it not be more straightforward to offer a compact API for just >> those sorts of use-cases -- the "fake update from nothing to something" >> use-cases? > > Maybe, but would anything else besides svnrdump use this new API? svn > checkout/export solve this in a different manner already. Well, in retrospect, I would name it something that did *not* have "checkout" in the name: svn_ra_do_export(), or svn_ra_dump_tree(), or something. And actually, I suspect that 'svn export' could use exactly this function! ('svn checkout' could not, because it really *is* an update under the hood.) But of course, it wouldn't do so because it prefers the more performant async approach. All of which leads us back to turning away from the send-all/non-send-all focus, and onto, as you said, limiting ourselves to a single auxiliary fetch connection. Still, we have to have a way to sensibly decide when to do so. 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. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature