I forwarded the "SVNAllowBulkUpdates Off" question to the us...@subversion.apache.org
list and here's the reply:
On Jul 7, 2013, at 11:11, Lieven Govaerts wrote:
On Sun, Jul 7, 2013 at 4:48 PM, Kyle McKay <mack...@gmail.com> wrote:
On Jul 7, 2013, at 06:39, Daniel Shahaf wrote:
Kyle McKay wrote on Sat, Jul 06, 2013 at 19:46:40 -0700:
On Jul 6, 2013, at 19:23, Jonathan Nieder wrote:
Kyle McKay wrote:
Unless bulk updates are disabled when using the serf access
(the only one available with svn 1.8) for https?: urls,
apply_textdelta does indeed get called multiple times in a row
without an intervening temp_release.
You mean "Unless bulk updates are enabled" and "without an
The problem seems to be skelta mode although it may just be the
that ra_serf has multiple connections outstanding and since
ever has one it can't happen over ra_neon.
If the server disables bulk updates (SVNAllowBulkUpdates Off) all
clients are forced to use skelta mode, even ra_neon clients.
As Brane and I have pointed out, git-svn can instruct libsvn_* to
bulk updates regardless of the server version, by setting
SVN_CONFIG_OPTION_HTTP_BULK_UPDATES (new in 1.8).
If you have questions about that, though, please address them to
us...@subversion.apache.org (the proper list for API usage
not to me personally.
According to the table at
if the server sets SVNAllowBulkUpdates Off, the client will be
forced to use
skelta no matter what the client setting is.
Indeed, the server admin has the final say in which mode is actually
used. SVNAllowBulkUpdates Off is only advised if the server admin
wants a log line per accessed resource. I doubt it's used a lot, but
the option is there.
Is that table incorrect?
No, that table is correct.
So the final say so on whether or not bulk updates are allowed is on
the server side which means git-svn really needs to handle skelta mode
on the client side properly when using ra-serf to guarantee
functionality with all subversion server configurations.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html