[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 2916] New - Subversion is not always a good steward of its HTTP(S) network connections

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-09-10 17:13:25 CEST

Erik Huelsmann wrote:
>> The obvious and universal fix is to always spool server responses to disk as
>> they come down, and then read back the spool. (This was, in fact, the solution
>> employed for issue 2048.) There are some similarly obvious cons to that
>> solution, too (disk space usage, the perception of nothing happening until the
>> spooling is done and the response is re-read from disk, extra I/O overhead,
>> etc.) And these pros and cons vary depending on whether we are trying to spool
>> a "full update" versus a "skelta"-type response.
>
> You are aware that this approach can be enabled by changing one FALSE
> to TRUE in libsvn_ra_neon, right? I mean, if this can pose a problem
> like that, shouldn't we just do that? (Instead of filing this issue,
> maybe even?)

There are two booleans of interest in ra-neon, and I don't know which one
you are alluding to:

   skelta? yes/no
   spool-the-response? yes/no

Four permutations, each with a unique set of pros and cons. Simply
switching to a skelta model (like ra-serf uses) is not a full solution so
long as the primary connection is paused while we take time to fetch file
contents or something on a secondary connection. So yes, I believe that
ra-serf suffers from this bug, too. The harder problem to deal with is the
user perception issue -- can you imagine during 'svn checkout', having
Subversion show you *nothing* by way of output while it spooled your
entirely checkout to a single massive on-disk file, then after twenty
minutes or so, barfed a couple thousands of lines of output at you as it
quickly flew over the spool file and actually performed the checkout-y stuff?

As a side-topic, I believe there is often some value in filing issues even
for so-estimated quick fixes when one wishes to maximize the audit trail. A
different set of folks track changes to issues than watch our commits list.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Mon Sep 10 17:10:05 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.