[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] Revision graph status and plan

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 27 Aug 2008 18:32:43 -0400

On Wed, Aug 27, 2008 at 4:58 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Aug 27, 2008 at 1:34 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
>> I've committed a little change. Now the merge information is stored,
>> but not shown in the graph yet. I store just the first nesting level.
>> I'm using a "level" integer to know in which nesting level I am, and I
>> ignore any log message deeper than level=1
>> The implementation works with any value of "includeMergedRevisions".
>> If "false" it simply won't know anything about merge information.
>> I'm going to try to include the information in the graph output.
> On Subversion's own repository, this command essentially never ends:
> svn log -g -rHEAD:0
> Until the API gives us more control, I wonder if we could do things
> differently to get a performance compromise? For example, maybe we
> could just build the cache we do now, and provide a context option on
> a revision node to get the mergeinfo "on demand" for just that
> revision? This could update the cache for next time.
> We could also maybe do it on demand as the graph is built, but that
> would make performance really inconsistent.
> I think we need to figure out some kind of way to defer getting the
> information. Ideally the cache can still be updated when we do get it
> though.

Just to follow up. I have a local copy of the SVN repository I test
with. Here are some timings:

$ time svn log -rHEAD:0
file:///Users/mphippard/repositories/svn-mirror > /dev/null

real 1m27.066s
user 0m3.582s
sys 0m6.431s

$ time svn log -g -rHEAD:0
file:///Users/mphippard/repositories/svn-mirror > /dev/null

real 20m10.677s
user 11m5.939s
sys 3m12.391s

It used to take about 10 minutes for the revision graph cache to
build. So the above 1+ minute command took roughly 10 times longer.
If the ratio holds, and it might not, the second command would have
taken over 3 hours to finish.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-08-28 00:32:52 CEST

This is an archived mail posted to the Subclipse Dev mailing list.