[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 07 Apr 2008 11:16:47 -0500

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.


Received on 2008-04-07 18:17:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.