On 6/22/06, C. Michael Pilato <cmpilato@collab.net> 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 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?
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?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 23 00:05:24 2006