Re: [PATCH 0/2] allow git-svn fetching to work using serf

On Jul 6, 2013, at 18:37, Jonathan Nieder wrote:

Kyle McKay wrote:

quoted

On Jul 6, 2013, at 17:28, Jonathan Nieder wrote:

quoted

David Rothenberger wrote:

quoted

On 7/5/2013 8:41 PM, Kyle McKay wrote:

quoted

quoted

quoted

quoted

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?

[...]

quoted

Begin forwarded message:

[...]

quoted

quoted

[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