Erik Huelsmann wrote:
> On 6/22/06, C. Michael Pilato <firstname.lastname@example.org> wrote:
>> Erik Huelsmann wrote:
>> > Way before 1.0, we used to build up 1 enormous log file with all
>> > commands to bring a working copy in order after 'svn up'. This had the
>> > additional benefit that any command written to this log would be
>> > processed after all network activity was done. In order to support
>> > 'Interactive merge tools' we dry-run--internal-(non-interactive)-merge
>> > while receiving network data, but write a log-command to do the actual
>> > merge at log processing time (possibly using [external] interactive
>> > tools).
>> > To improve performance, we split up this enormous log into several
>> > small logs. Most of these log files are processed at close_file-editor
>> > callback time. This will be (most of the time) in the middle of
>> > network activity.
>> > The above probably means that we have regressed at supporting
>> > interactive merge tools.
>> I'm not seeing in your summary above the part that means we've
>> regressed at
>> supporting interactive merge tools. Is it because by doing the
>> merge invocations "in the middle of network activity", we run the risk of
>> the network stream backing up (due to not being read from) and a server
>> timeout dropping the connection?
> Ah sorry to leave that part out. Yes, the risk of the server dropping
> the connection raises greatly when using interactive tools instead of
> non-interactive ones. That was in fact the reason why we used to do
> the interactive merges at the end of the report.
> Hope that's more clear?
Yep. So, I'm not sure if this is really a problem for svnserve at all (but
could be wrong here). And it might not be a problem over ra_dav either
because that big, long REPORT response is spooled to disk before any of it
is parsed (during which time only shorter-lived network requests happen --
individual GETs and PROPFINDs, IIRC). (See the history of issue #2048.)
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Jun 23 00:33:39 2006