[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1417639 - in /subversion/trunk/subversion/mod_dav_svn: dav_svn.h mod_dav_svn.c reports/update.c

From: Lieven Govaerts <lgo_at_mobsol.be>
Date: Fri, 7 Dec 2012 08:47:21 +0100

On Wed, Dec 5, 2012 at 10:50 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Dec 05, 2012 at 03:54:00PM -0500, Mark Phippard wrote:
>> On Wed, Dec 5, 2012 at 3:46 PM, <lgo_at_apache.org> wrote:
>> > Author: lgo
>> > Date: Wed Dec 5 20:46:33 2012
>> > New Revision: 1417639
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1417639&view=rev
>> > Log:
>> > Add a Force option to SVNAllowBulkUpdates. This allows a server admin to always
>> > respond to an update-report request with all content and properties inline.
>> > Now that skelta mode will be the new default with ra_serf, this feature can be
>> > useful in certain situations where the admin wants to avoid the overhead
>> > of per-file GET requests (e.g. with per-request Kerberos authentication).
>> I appreciate that you are doing *something* here, but I still wonder
>> if this is the right thing. It seems like it would be better if a 1.8
>> client tried to negotiate for the right to use skelta mode and it
>> required a specifically configured 1.8 server to allow it. I see two
>> problems with your approach:
>> 1) Users running older servers, who are perhaps the most vulnerable to
>> the new behavior, will not get any relief when 1.8 clients become the
>> norm.
>> 2) Wouldn't this new option break any users that happen to be using
>> Serf with a pre-1.8 client?
>> I think Serf clients should default to "sendall" mode unless the
>> OPTIONS includes something that says it is OK to use skelta mode.
>> This would force 1.8 clients to behave like Neon clients when talking
>> to older servers and it would allow admins that upgrade their servers
>> to 1.8 to get whatever benefits they see from enabling the skelta
>> mode.
>> Just my 2 cents
> Makes sense.
> We could also consider making 1.8 server advertise skelta mode capability
> by default, with an option to turn it off,

That's de facto what happens, although the wording of the options is
slightly different.
A 1.8 server will now always send the SVN-Allow-Bulk-Updates header,
with "On|Off|Prefer" as possible values. By default this value is set
to On (default value of SVNAllowBulkUpdates), so the client is allowed
to decide, which in case of a 1.8 client with ra_serf is skelta mode.

> so that 1.8 clients will negotiate
> skelta mode with 1.8 servers by default, but not with earlier servers.
> This way, 1.8 clients talking to 1.8 servers can take advantage of skelta
> mode, while clients talking to older servers won't stress out existing
> installations by default.

As I already responded to Mark, I haven't changed the ra_serf defaults
to this proposed behavior, but the option is now there.

> In the 1.8 release notes We can raise attention in the fact that a 1.8
> server should turn off skelta mode if necessary, such as when each GET
> request causes an authentication request to LDAP.

Yeah, we should explain what the new default behavior of a 1.8 client
is, and in which situations the admin can alter it with
"SVNAllowBulkUpdates Prefer".

Received on 2012-12-07 08:48:16 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.