subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C. Michael Pilato" <>
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
Date Thu, 14 Feb 2013 14:09:46 GMT
On 02/14/2013 04:04 AM, Johan Corveleyn wrote:
> On Thu, Feb 14, 2013 at 1:20 AM, Bert Huijben <> 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.)

C. Michael Pilato <>
CollabNet   <>   <>   Enterprise Cloud Development

View raw message