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 interactive
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?
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Jun 23 00:00:41 2006