[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_apache.org>
Date: Thu, 6 Dec 2012 00:18:05 +0100

On Wed, Dec 5, 2012 at 9:54 PM, Mark Phippard <markphip_at_gmail.com> 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.

That's not how mod_dav_svn works now, the client negotiates the right
to use bulk_update mode, which the server can accept (default) or deny
by using the SVNAllowBulkUpdates flag. Given this flag already exists,
it seems most logical to try and reuse it instead of adding a new
option with the inverse meaning.

> 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.

I had no intention to change the default behavior of serf with this
patch, in fact, that is a choice orthogonal to what I want to achieve
The intention here is for server admins to decide if their setup is
known to be not ready for parallel update.

> 2) Wouldn't this new option break any users that happen to be using
> Serf with a pre-1.8 client?
Yes, indeed it will. I haven't really thought yet about whether or not
that's a problem. If it is, then that means we have no possibility to
give the admin the option to "force" the use of bulk updates. The
closest alternative than is to make it a "Prefer" option, and use
OPTIONS to ask the client to kindly respect the server's preference
for bulk updates. Which a pre-1.8 client with serf will then ignore.

> 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.

Again, this was not the purpose of this patch, but this can be added
provided that's what the svn dev community decides is the best

> Just my 2 cents

> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/

Received on 2012-12-06 00:19:00 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.