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

RE: svn commit: r1445973 - in /subversion/trunk/subversion: include/svn_ra.h include/svn_repos.h libsvn_repos/rev_hunt.c tests/libsvn_repos/repos-test.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 14 Feb 2013 15:44:06 +0100

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: donderdag 14 februari 2013 15:10
> To: Johan Corveleyn
> Cc: Bert Huijben; Bert Huijben; dev_at_subversion.apache.org
> Subject: Re: svn commit: r1445973 - in /subversion/trunk/subversion:
> include/svn_ra.h include/svn_repos.h libsvn_repos/rev_hunt.c
> tests/libsvn_repos/repos-test.c
>
> On 02/14/2013 04:04 AM, Johan Corveleyn wrote:
> > On Thu, Feb 14, 2013 at 1:20 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> >> We currently fetch all the revision numbers (inserted in an array in the
> >> wrong order.. which we then reverse) and then start delivering changes.
> >>
> >> I would be surprised if the revision/path walk step would make a huge
> >> difference compared to delivering the actual changes (We now always do
> that
> >> before the first revision, so it is not slower than the current server side
> >> algorithm). But if it is we can optimize it later.
> >
> > I'm pretty sure this can make a big difference if you're blaming files
> > with a long history. I'm talking about files with a couple thousand
> > revisions, which date back to, say, r100, and run up to r200,000. If
> > caches are cold (which usually is the case for those very old
> > revisions), it can take minutes for the server to crawl history and
> > collect all those revs. During those minutes, the client is just
> > waiting, twiddling its thumbs, holding all of its CPU power ready for
> > pulling the first revisions through its diff algorithm :-).
> >
> > But you're right of course, that this can be optimized later.
>
> On the plus side, at least Bert didn't introduce anything unique here --
> 'svn log' does precisely the same thing when asked to produce logs from
> OLDER_REV to NEWER_REV. (Still, I agree that the process isn't ideal.)

I followed up with Johan using a Dutch private mail and he was interested in seeing the performance improvements.

I applied these changes today, with an ra-capability exchange to allow choosing between implementations without waiting for an error.

        Bert
Received on 2013-02-14 15:44:54 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.