[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 5 Dec 2012 15:54:00 -0500

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

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-12-05 21:54:36 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.