On Wed, Dec 5, 2012 at 6:18 PM, Lieven Govaerts <lgo_at_apache.org> wrote:
> 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.
Given that this can be implemented as new code, I do not think it is
relevant how it works pre-1.8. For example, for things like merge
tracking the server responds to the OPTIONS request with info that
lets the client know it can use those methods. Why couldn't we do the
same for skelta updates? (ASIDE: I am never sure how to describe the
two possible modes)
If a 1.8 serf client looked at the OPTIONS response to know if it can
send this kind of request then old servers would never include this
info and therefore Serf would only send Neon-style requests to those
servers. IMO, this is the right behavior we should adopt.
A 1.8 server could be configured to include this in the OPTIONS
request. We can debate whether a 1.8 server should do this by
default, with a configuration option to disable it, or whether it
should not do this by default with an option to enable it. I think it
should be the latter so that no one is surprised by the change.
>> 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
> here.
Understood. I was just expressing what "I" see as the problems.
Again, thanks for taking this on.
Is there an easy way to make svnrdump always use "sendall" mode? That
would remove the release blocker we have about this command not
working correctly with Serf and it seems like something we ought to be
able to implement independent of these other questions.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-12-06 16:12:17 CET