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