On Thu, Dec 6, 2012 at 4:40 PM, Lieven Govaerts <l...@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/
