Re: log -g performance

>> I just wanted to know why log -g operations are much slower than normal
>> log, even when the revisions don't have any merge-info change?
>
> I suspect this is just the overhead of checking -- for each revision --
> whether or not the revision has a mergeinfo change.

For SmartSVN's local log cache, we are using log -g to detect those
revisions which have mergeinfo, afterwards (resp. concurrently) we are
querying for the mergeinfo of that revisions. The actual merged revision
numbers are not used, so that's quite an overhead, but AFAIK there is no
more efficient way to retrieve complete mergeinfo for a range of revisions?

In this case I would like to make an RFE to provide more efficient
access to the mergeinfo. Currently I can see two alternative approaches:

(1) Have a range parameter for the "get-mergeinfo" command

(2) Have an additional "recursion depth" parameter for log -g. Depth 0
would mean that the server should just signal that there is mergeinfo
resp. there are merged revision but should not send them.

While (1) would probably be more efficient, (2) would definitely be a
surplus for command line users too: From the (rather bare) experience we
have made with log -g so far, it's likely going to report more than a
user needs. For example, we have a shared code base with three active
and persisting "feature branches". A normal log reports 462 revisions,
log -g reports 19542 revision, up to recursion depth 8 or so ...

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
C. Michael Pilato wrote:
> Leonardo Fernandes wrote:
>> Hi.
>> I just wanted to know why log -g operations are much slower than normal
>> log, even when the revisions don't have any merge-info change?
> 
> I suspect this is just the overhead of checking -- for each revision -- 
> whether or not the revision has a mergeinfo change.  This penalty is 
> small where no mergeinfo exists at all, but gets larger once mergeinfo 
> appears in the repository (and grows depending on the depth, 
> directory-wise, of the places where mergeinfo is set).
> 
> (Is that right, David?)
> 
> I think we could improve this by changing the way we detect these 
> differences.  Today, we do so by fetching all the mergeinfo in one 
> revision, then all the mergeinfo in another revision, and then comparing 
> them.  We'd probably be better served by adding an 
> svn_fs_mergeinfo_diff() function that could avoid crawling into 
> unchanged regions of the respective revision trees to even find 
> mergeinfo (since the mergeinfo found in both subtrees would be 
> identical, and thus not present in a diff of the two anyway).
> 
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org