Re: log -g performance
From: Marc Strapetz <marc.strapetz_at_syntevo.com>
Date: Tue, 24 Jun 2008 12:16:01 +0200
> One of the things I was thinking was that it would be nice (assuming
That would be helpful as well. The suggested depth parameter requires a
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.orgReceived on 2008-06-24 12:16:28 CEST
This is an archived mail posted to the Subversion Dev mailing list.