Re: svn log -g on repository root -- ouch

C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> Mark Phippard wrote:
>>> $ svn log --limit=25 http://svn.collab.net/repos/svn
>>> real 0m2.014s
>>> user 0m0.022s
>>> sys 0m0.014s
>>>
>>> $ svn log -g --limit=25 http://svn.collab.net/repos/svn
>>> real 7m11.116s
>>> user 0m0.023s
>>> sys 0m0.013s
>>>
>>>
>>> I do not know how bad it is hurting the server during all that time,
>>> but the worst part is that the command output does not even contain
>>> any merge information.
>>
>> One of the limitations of 'log -g' is that it traces the full history
>> for the paths being examined, so that it can later determine branching
>> information when tracing branch history. This is much akin to running
>> 'svn log $REPOS_ROOT -r1:HEAD', which also buffers all the log
>> information before sending it. Running 'log -g' on the repo root
>> causes this, as well as buffering for any merges created. I know it's
>> ugly, but we need the history information so to determine when merges
>> "re-attach" to a common line of history.
>
> Are we walking the history with the svn_fs history APIs, or using the
> get_location_segments type of logic? Do we need to know every change
> along the way, or only "changes of address" points?

We're using the svn_fs history APIs, because we need to know which
revisions the mergeinfo changed in, as well as the log information for
any change revision. Maybe we could split the work up into different
passes over the history, but I don't know that that would help.

-Hyrum