Hi,
On Sat, Dec 1, 2012 at 10:18 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> [ changing subject to make topic more visible]
>
> On Sat, Dec 1, 2012 at 9:00 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Sat, Dec 1, 2012 at 12:36 AM, Justin Erenkrantz
>> <justin_at_erenkrantz.com> wrote:
>>> On Fri, Nov 30, 2012 at 4:54 PM, <cmpilato_at_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.
>
r1417639 and r1417642 respectively give the server admin and the user
the option to force the use of bulk updates.
Changes are ready for review and use.
I haven't changed any of the defaults in ra_serf and mod_dav_svn.
Lieven
Received on 2012-12-05 22:00:31 CET