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