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.
As for the lack of merge information, it would seem that mergeinfo isn't
getting fetched for children. Since we rely on svn_fs_get_mergeinfo()
to provide that information, I suspect it's a problem with that API.
Dave, could you take a look at this?
-Hyrum
Received on 2008-03-28 16:41:22 CET