On Jul 6, 2013, at 18:37, Jonathan Nieder wrote:
Kyle McKay wrote:
On Jul 6, 2013, at 17:28, Jonathan Nieder wrote:
David Rothenberger wrote:
On 7/5/2013 8:41 PM, Kyle McKay wrote:
Daniel Shahaf has suggested also setting
"servers:global:http-bulk-updates=on".
I have a patch that does this, but since turning on bulk updates
has
a possible performance penalty, I prefer your approach.
I assume that's because http-bulk-updates defeats caching. If so,
makes sense.
Please forgive my ignorance: is there a bug filed about ra_serf's
misbehavior here? Is it eventually going to be fixed and this is
just a workaround, or is the growth in temp file use something we'd
live with permanently?
[...]
Begin forwarded message:
[...]
[2] http://subversion.tigris.org/issues/show_bug.cgi?id=2932
Ah, thanks for the context.
It's still not clear to me how we know that ra_serf driving the editor
in a non depth-first manner is the problem here. Has that explanation
been confirmed somehow?
For example, does the workaround mentioned by danielsh work? Does
using ra_neon instead of ra_serf avoid trouble as well? Is there a
simple explanation of why violating the depth-first constraint would
lead to multiple blob (i.e., file, not directory) deltas being opened
in a row without an intervening close?
Using ra_neon seams to eliminate the problem. Using ra_neon has always
been the default until svn 1.8 which drops ra_neon support entirely
and always uses ra_serf for https?: urls.
The workaround mentioned by danielsh won't work if the server has
configured SVNAllowBulkUpdates Off because that will force use of
skelta mode no matter what the client does. However, since ra_neon
only ever has a single connection to the server it probably doesn't
matter.
Since ra_serf makes multiple connections to the server (hard-coded to
4 prior to svn 1.8, defaults to 4 in svn 1.8 but can be set to between
1 and 8) it makes sense there would be multiple active calls to
apply_textdelta if processing is done as results are received on the
multiple connections.
Kyle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html