[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 28 Mar 2008 12:08:31 -0400

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?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-03-28 17:08:44 CET

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.