svn log -g performance for large commits

This is from an email conversation with C. Michael Pilato about the
performance
degradation of 'svn log -g' involving revisions with plenty of changed
paths.

BTW: as a workaround would it help to split a large commit into several
smaller
ones so that mergeinfo examination can be skipped for revisions that
don't
contain the log target?

Regards,
  Thomas

Email conversation follows:

Thomas Becker wrote:

> Is it true that svn log -g will examine all paths for merge-info
affected in a
> particular revision? From my layman point-of-view it would suffice to
examine
> just the path (and parent paths) for which the log was requested.
Could you
> shed some light on this, or is there any workaround?

C. Michael Pilato wrote:

> 'svn log' is by its very nature recursive. When you request the logs
for a
> directory, you are necessarily requesting them for all the children of
the
> directory, too. 'svn log -g' is no different, extending its search
for
> mergeinfo changes into any of the changed paths that are at or under
the log
> target itself. It's a bummer, to be sure, especially when big commits
are in
> the history.
>
> One thing I've considered in the past is the implementation of
--depth=empty
> support for 'svn log', which in the default case (and when run against
a
> directory target, of course) would show only revisions in which the
> directory's properties changed (svn:ignore, svn:mergeinfo, etc.). In
the
> 'svn log -g' case, it would have the effect of only doing the
mergeinfo
> examination and recursion based on mergeinfo changes on the target
directory
> only, regardless of what might have changed "under" the directory.
>
> What do you think? Would this be useful?

Thomas Becker wrote:

> OK, I understand that a change in a path is also accounted to the
parent of
> that path. For this scenario it sure would be useful to be able to
restrict
> the scope of the log command.
>
> In our case however, I think it's a bit different: the performance of
the log
> of a path is affected by the number of "siblings" in any revision
involved in
> the log, e.g.
>
> r123455
> M /x/y/0000.txt
>
> r123456
> M /x/y/0000.txt
> ...
> M /x/y/9999.txt
>
> r123457
> M /x/y/0000.txt
>
> When requesting the log excluding revision 123456 (the one with many
changed
> paths) it performs fast (e.g. 'svn log -g -r 0:123455 <url>' or
> 'svn log -g -r 123457:HEAD <url>' where <url> is
> file:///C:/Repos/XY/x/y/0000.txt). Whenever revision 123456 is
involved,
> performance degrades for 'svn log -g'. This leads me to the conclusion
that
> 'svn log -g' examines all paths in r123456, even the "siblings" of
0000.txt
> which should have no impact on the collection of mergeinfos for
0000.txt. But
> maybe I'm totally wrong here?

C. Michael Pilato wrote:

> Ah! It is the case that the FS API for asking "Which paths were
changed in
> this revision?" are exhaustive -- you can't ask for just the changed
paths in
> and under some level. And generally speaking you have to iterate over
those
> paths, ruling out the ones that don't apply to find the ones that do.
>
> Now ... it occurs to me that there might be some optimization possible
here.
> I mean, if you're running log against a single file, and you haven't
specified
> -v, then perhaps we can do a more direct mergeinfo comparison.
>

Thomas Becker wrote:

> This optimisation would be a great improvement for us as I suspect it
wasn't
> the last time that we applied a change to a lot of files in one
revision (e.g.
> change of file header comments or svn:keywords property).

--
Software Development, Torex
T: +49 (0)30 49901-0 E: thomas.becker_at_torex.com
Torex Retail Solutions GmbH, Salzufer 8, D-10587 Berlin
T: +49 (0)30 49901-0  F: +49 (0)30 49901-139  www.torex.de