Hi,
On Thu, Dec 6, 2012 at 11:04 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Dec 6, 2012 at 4:40 PM, Lieven Govaerts <lgo_at_apache.org> wrote:
>
>> 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.
>
> My main concern with reusing this flag is that I did not want to force
> us down a path where we are recommending users setup their server with
> SVNAllowBulkUpdates off because this option will impact all users
> running pre-1.8 clients (Neon). Assuming prefer does not impact Neon,
> it sounds like there would be little reason for someone to use off
> unless they really wanted that behavior for all clients.
>
If you want to advise users to profit from the skelta-mode in serf,
than they should use the default On.
If you want to advise users to stick to the old neon-style mode of
bulk updates, they should set it to Prefer.
Setting Off for this flag still has its old purpose, when its
mandatory that all individual file accesses are logged, for new and
old clients.
>> 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.
>
> What will a Neon client do with Prefer? Just ignore it and treat it like On?
>
A pre-1.8 neon client will not see this new header, so it will send
the "send-all" header in the update-report. The server treats this as
"I've told the client my preference, now do what the client asks me
to", so the server will use the bulk update mode, just like before.
A 1.8 neon client doesn't exist.
>> (*) 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.
>
> Overall it is good, but I guess I just happen to think it does not
> cover the case that I thought was most important (older servers). It
> does at least give those users an incentive to upgrade since they can
> then control the behavior if they need to. I guess we would have to
> tell these users to beg their users to edit their local configs in the
> meantime?
>
It doesn't set the default of serf to bulk when talking with older
servers, that's true. But the mechanism is there, should we decide
that's the correct thing to do it's easily added.
>>> 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?
>
> AFAIK, it is only dump where the svnrdump tool fails when using Serf.
> Because of the Ev1 stuff. Using bulk-updates ought to avoid that
> issue.
Actually, my proposed hack of forcing ra_serf to use bulk update mode
is not going to work. If the server has SVNAllowBulkUpdates set to
Off, bulk update mode isn't available, the server will ignore any
requests from the client and force skelta mode.
If I remember correctly the issue here was responses arriving out of
order due to multiple parallel connections. So the fix until svnrdump
has moved to Ev2 is to stick to one extra connection for all the file
content requests, so all of those responses arrive in sync.
Don't know how easy that is to do, I wonder if we have a simple
mechanism that allows a client to pass ra implementation specific
options.
>I wonder if there is an XFail test currently?
No:
lgo-macbp:trunk lgo$ cat subversion/tests/cmdline/svnrdump_tests.py | grep XFAIL
lgo-macbp:trunk lgo$
The parallel connections are only opened after a minimum number of
requests, probably our svnrdump test repository aren't big enough.
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Lieven
Received on 2012-12-07 08:40:33 CET