On Thu, 12 May 2005, D.J. Heap wrote:
> In addition to your comment, I found there was a pool issue in the previous
> patch.
>
Yeah, I saw the sendpool. How easy isn't it to get confused by these
pools? :-)
> Log:
> Optimize 'svn log --limit' performance by reading histories for
> paths together as proposed by Greg Hudson.
>
Now it's optimized even without --limit, so "Make svn log streamy in most
cases..." or something? It gets a nicer summary when someone goes back and
writes the CHANGES file:-)
>Index: subversion/libsvn_repos/log.c
>===================================================================
>--- subversion/libsvn_repos/log.c (revision 14714)
>+++ subversion/libsvn_repos/log.c (working copy)
> svn_error_t *
> svn_repos_get_logs3 (svn_repos_t *repos,
> const apr_array_header_t *paths,
>@@ -217,11 +419,14 @@
>+ /* Get an ordered copy of the start and end revisions and allocate
>+ a revision list buffer if they want history in forward order. */
>+ if (start > end)
>+ {
>+ hist_start = end;
>+ hist_end = start;
>+ }
>+
This comment seems out of date. The allocation doesn't happen here.
>+ /* They want history for the root path, so every rev has a change. */
>+ int count = hist_end - hist_start + 1;
>+ if (limit && count > limit)
>+ count = limit;
>+ for (i = 0; i < count; ++i)
> {
>- int i, matched = 0;
>- for (i = 0; ((i < revs->nelts) && (! matched)); i++)
>- {
>- if (this_rev == ((svn_revnum_t *)(revs->elts))[i])
>- matched = 1;
>- }
>-
>- if (! matched)
>- continue;
>+ svn_pool_clear (sendpool);
>+ /* If they wanted it in reverse order we can send it completely
>+ streamily right now. */
This comment also seems slightly out-of-date now.
>+ if ( start > end )
And here is the famous spacing:-)
Else it looks good.
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 13 08:16:22 2005