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.
> 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?
> (*) 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?
>> 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. I wonder if there is an XFail test currently?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-12-06 23:05:18 CET