The skip is basically pulling every commit up to the desired page, and then iterating through them until it finds the start of the page
ah. we should fix that
Problem is that it's hard, maybe impossible, to efficiently convert a skip to a start rev.
guess & iterate?
Some of the SCMs support it, but only one of the tree
I don't recall of the top of my head
seems like since they're linear ints
it'd still help
i'll ticket it up
Though hg also has support for revisions-to-commits built-in, since the way it does branching is very different
We could certainly make the next paging efficient, since we'll know the last revision. But that won't help for jumping around pages
Oh, it wouldn't work for SVN either, though, because of the path param
You can't know a priori what commits touched a path
Hrm. If I added repo_ids to the new LastCommit model (would be nice to have anyway), then we could potentially get a list of all commits that touched a path with a single query. Might not be too inefficient. Then could cache that on the page to do paging with
Would only work for the repos that pre-compute the LCDs, but I'm not entirely convinced that our idea about SVN being too slow to pre-compute stuff on refresh is really valid
It's actually faster than git, in my experience
Since it doesn't have to hit a separate process
And it's especially fast for LCD, since it can pull all the LCD info in one request to SVN instead of having to walk up the tree
But, admittedly, my test case for SVN was smaller than my test case for git
We should also limit the max page size to constrain the runtime of this page. The default option of 250 is probably too high unless we can make a lot of speedups.
Log in to post a comment.