On Thu, Feb 14, 2013 at 3:44 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----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.
Yay! Although ... Bert tricked me into raising my hand for working on the client part of the "backwards walking blame" :-). Unless someone else does it first of course, hint hint (I'm pretty slow, so that shouldn't be all that hard ;-). -- Johan