Re: log -g performance

On Wed, Jun 18, 2008 at 9:16 AM, Marc Strapetz
<marc.strapetz_at_syntevo.com> wrote:
>>> 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 ...

One of the things I was thinking was that it would be nice (assuming
it is not expensive), if a normal svn log could just return some kind
of boolean for each revision that indicates if the revision was the
commit of a merge. In the normal output, maybe an * could be added
somewhere. Anyway, API users could use this boolean to do a followup
request for those revisions which are merges to get the mergeinfo for
that revision. Presumably this would make it easier to build a
responsive UI as you could defer getting the mergeinfo until you
needed it.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org