> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: donderdag 14 februari 2013 15:10
> To: Johan Corveleyn
> Cc: Bert Huijben; Bert Huijben; dev@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 <b...@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
