Hi,
On Thu, Dec 6, 2012 at 3:44 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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)
It is relevant because we already have a SVNAllowBulkUpdates flag that
gives the admin some options to define this exact behavior. That flag
gives the admin the option to disable bulk updates, to ensure that
each individually request gets logged in access.log.
Since it's perfectly possible to reuse the same flag with both options
keeping their same meaning, I don't want to change that.
> 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.
>
With r1418071 and r1418077 the mechanism is now as follows:
- with a 1.8 server, the admin can express how (s)he wants the clients
to send update requests:
SVNAllowBulkUpdates Off: only skelta mode allowed (as-is)
SVNAllowBulkUpdates On: the client decides what mode to use (as-is)
SVNAllowBulkUpdates Prefer: a well-behaved client should use bulk update mode.
- a 1.8 ra_serf client will read the OPTIONS header representing the
above 3 options.
if the 1.8 server wants bulk mode Off or Prefer this is respected directly.
(*) if the 1.8 server allows bulk mode but doesn't prefer it,
ra_serf will use skelta mode.
(*) If an older server doesn't send the header, ra_serf will use
skelta mode (still the default)
- the latter two options marked with (*) can be configured by the user
with the bulk-updates option.
I think this implements all options that are needed, and what you are
suggesting except for the default mode to older servers.
>>> 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.
>
A bit of a hack, but after the config is read from file/registry and
before svnrdump creates the ra_session we can set the global or per
server-group "bulk-updates" option in memory to true.
Is this for dump only?
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Lieven
Received on 2012-12-06 22:41:50 CET