[ changing subject to make topic more visible] On Sat, Dec 1, 2012 at 9:00 PM, Mark Phippard <markp...@gmail.com> wrote: > On Sat, Dec 1, 2012 at 12:36 AM, Justin Erenkrantz > <jus...@erenkrantz.com> wrote: >> On Fri, Nov 30, 2012 at 4:54 PM, <cmpil...@apache.org> wrote: >>> >>> Author: cmpilato >>> Date: Fri Nov 30 21:54:35 2012 >>> New Revision: 1415864 >>> >>> URL: http://svn.apache.org/viewvc?rev=1415864&view=rev >>> Log: >>> Implement in ra_serf "send-all" mode support for update-style REPORTs >>> and their responses. (Currently disabled by compile-time conditionals.) >>> >>> (This one goes out to Ivan Zhakov.) >> >> >> I've stated for a long time that I think the send-all mode is a huge mistake >> architecturally because it is too prone to double-compression and TCP >> pipeline stalls and is a tremendous burden on a properly-configured httpd >> (by not taking advantage of server-side parallelism), it's nice to see it's >> not *too* hard to shoehorn this bad idea back into ra_serf. We'd never be >> able to shove the non-send-all approach into ra_neon. =) > > Just to be clear, I do not believe anyone is suggesting we completely > abandon the non-send-all approach. I like that this approach can > offer good performance on a well-configured server as well as enable > new features/ideas such as not even fetching the full-texts that we > already have locally. I think the question is simply what is the best > way to deliver this. Completely agree.
My point was that in theory skelta-mode is cool, but it still needs a lot of work to get it really done. So let's release ra_serf by piecemeal, because we also have significant amount of ra_serf issues unrelated to update editor. > >> Here's my suggestion for consideration - let's experiment with this setting >> in the beta release process with the setting as-is - that is we always do >> the parallel updates unconditionally (except perhaps when svnrdump is being >> stupid). If we get real users complaining about the update during that >> cycle, we can then figure out either switching the default and/or adding a >> config-option or even allowing some control via capabilities exchange. > > I feel pretty strongly that we should at minimum use the send-all > approach when talking to pre-1.8 servers. Even though in some > situations it could still offer good performance. I just think it > would be more respectful to our users (server admins in this case) to > not change this behavior in a way that could surprise them. Maybe we > could come up with exceptions, such as older servers that are using > the SVNAllowBulkUpdates off directive. In that situation we should > use the new behavior since that is basically what that directive is > asking for. > > As I said in another thread, I think we should treat a 1.8 server the > same way and require someone that was upgrading to add some new > directive to enable the new feature. This would allow a server admin > to setup his server correctly, including using things like > mod_deflate, and turn on the new behavior rather than get it > automatically simply because they upgraded their binaries. > > This seems like it satisfies everyone. Existing users, especially > those running older server versions, would not be surprised by new and > unwanted client behavior, and it would still be easy to configure a > new server properly to support the non-send-all mode when it was > desired. I just do not see what the downside would be to approaching > it this way. > +1. -- Ivan Zhakov
