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.)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-02-14 15:10:30 CET