You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2006/06/22 21:51:50 UTC
Regression: Interactive merge support
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.
Comments?
I hope to change libsvn_wc so that we can run the actual merges at
close_edit/finish_report time (ie: after all network traffic). But in
order to do that, we may need a way to record - on disc - the fact
that files have to be merged. Same as log files, to support svn
cleanup.
I could use a good idea or two for that too...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Regression: Interactive merge support
Posted by Erik Huelsmann <eh...@gmail.com>.
On 6/23/06, Julian Foad <ju...@btopenworld.com> 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.
> [...]
> > I hope to change libsvn_wc so that we can run the actual merges at
> > close_edit/finish_report time (ie: after all network traffic). But in
>
> Will this also bring us much closer to atomic updates - in other words, greatly
> reduce the chance of an update failing part way though? That would be lovely.
I'm not sure which problems all together make up the fact that updates
of working copies are non-atomic.
I did find out though that we used to run merge at a per file bases,
now we group all merges on a per directory basis.
My change (see 'Fix issue 1914') will bring that back to doing it per
file, leaving it to the close_directory routine to install the working
copy changes calculated by the per-file merges.
Hope that clarifies it a bit?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Regression: Interactive merge support
Posted by Julian Foad <ju...@btopenworld.com>.
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.
[...]
> I hope to change libsvn_wc so that we can run the actual merges at
> close_edit/finish_report time (ie: after all network traffic). But in
Will this also bring us much closer to atomic updates - in other words, greatly
reduce the chance of an update failing part way though? That would be lovely.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Regression: Interactive merge support
Posted by "C. Michael Pilato" <cm...@collab.net>.
Garrett Rooney wrote:
> On 6/22/06, C. Michael Pilato <cm...@collab.net> wrote:
>
>> 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.)
>
>
> On the other hand, I believe ra_serf does not do that spooling to disk
> trick...
Yeah, but who's going to use that? :-)
* cmpilato ducks.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Regression: Interactive merge support
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/22/06, C. Michael Pilato <cm...@collab.net> wrote:
> 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.)
On the other hand, I believe ra_serf does not do that spooling to disk trick...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Regression: Interactive merge support
Posted by "C. Michael Pilato" <cm...@collab.net>.
Erik Huelsmann wrote:
> On 6/22/06, C. Michael Pilato <cm...@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?
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Regression: Interactive merge support
Posted by Erik Huelsmann <eh...@gmail.com>.
On 6/22/06, C. Michael Pilato <cm...@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
Re: Regression: Interactive merge support
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand