Re: log -g performance

> 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.

That would be helpful as well. The suggested depth parameter requires a
protocol change from client to server and in case of depth=0 probably
also from server to client. How about this mergeinfo marker -- can it be
introduced safely without breaking older clients?

Can we get this topic into the issue tracker?

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Mark Phippard wrote:
> 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.
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org