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.) -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
