Paging support in revision log

[Cristi BALAN]

I sugest using something similar to svn log -r HEAD:HEAD-100 by default so users don't spend a lot of time waiting for all log messages to be retrieved if a file has a substantial number of revisions. IMO, this should be similar to the same functionality available in TortoiseSvn. example

Also, this should probably be implemented for viewing the revision list of a wiki page since, probably, most people rarely use the feature anyway.

[daniel]

This is a good idea. Thanks Christi! :)

[daniel]

Paging a'la #215, #216 would be good.

[daniel]

Cristi even. Sorry about that. :)

[chris@…]

+1 for paging

Clicking on the "Revision Log" link for source:/trunk​ takes quite a while for this to spit out the data. Should probably do the same for the XML feeds, only show the last X revisions. Where X is configurable in trac.ini

Since paging is such a common feature perhaps some common code could be written (an object maybe) but I don't like the idea of having to get back all the data before displaying. That slows things up alot just to display the number of pages available.

[Christian Boos]

In the patch attached to #1441 (support for path history), I changed the Node.get_history(self) method to Node.get_history(self, limit=None, skip=None), for being able to implement paging support.

So I guess I'm only a short step away…

[Christian Boos]

Indeed, there's now support for paging in [1545].

The implementation is fast for the common case, browsing the first n entries in the revision (n is 100 by default, which should be enough most of the time, and not too costly either).

There's no caching of the result however, so each next page (with "older" revisions) is send after having silently processed the early history.

Hum, now that I think about it, that's embarassingly stupid. I'll rework this :)

[Christian Boos]

Ok, now paging is done the right way, with [1550]. I'm not completely done with this ticket, however:

• setting the limit parameter interactively
• adding a stop at revision n parameter
• adding a stop at first copy checkbox
• + preparative steps for #199

[Christopher Lenz]

cboos, I can't say I understand the paging mechanism you implemented in [1550]. Can you please explain in more detail? Especially the pages parameter is weird… are you tracking the history of pages the user has already seen?

Furthermore, I'd prefer to keep the concept of paging at the web interface layer, and keep the repository implementations "dump". Is skipping a number of revisions really that expensive? And can't you just limit the number of revisions by breaking out of the history iteration early?

About your previous comment, let's not overcomplicate things. I don't see a need for the user to specifiy the limit, nor for an option to stop at a specific revision.

[Christopher Lenz]

s/"dump"/"dumb"

[ludde]

Did I understand this correcly?

• for each previous page you visited, the pages has an item (actually two). each such item contains the path/rev for the item on top of the page.
• so if you have visited 7 pages, and want to go to page 5, it fetches pages[5*2-1] and pages[5*2-2] (this is the path/rev for the first item in the list on the page), and then gets the next 100 items starting from there.
• if you want to go back to the first page, it looks at pages[0] and pages[1] and uses that as the path/rev of the first page.
• so any new commits that happen while you're browsing will not be shown to you, since it will always reuse pages[0] and pages[1] and those still point to the old first item

[Christian Boos]

answer to ludde's question

In ludde's explanation, points 1, 2 and 3 are correct.

Point 4 is also correct, but there's nothing wrong with that: if you are browsing the revision log, (either the path history or the node history), this revision log is explicitely for a given path/rev combination. So if a new revision occur, that won't change anything to the content of that revision log. This behavior has not changed (check with 0.8x for example).

Going to the first page doesn't mean going to the most recent revision, only going to the first page of all the pages for that path/rev revision log.

answer to cmlenz's observations

As for justifying the pages parameter: I understand it's not perfect: the URLs are quite long. But I think the alternatives are worse:

• storing that information in the session: this would be wrong. For example, this is what is currently done for navigating through the ticket list returned by the last query. That's sometimes annoying: you can't navigate two sequences of tickets, you can't easily go back to the normal sequence of tickets… I think this would be solved by adopting a similar approach to what I did for pages here.
• recomputing the full history preceeding the page actually seen: the more you get "deeper" in the history, the longer it will take, thereby defeating the purpose of paging…

I'm OK with the other points raised: I now simply stop the iteration at the log module level, not in the versioncontrol layer anymore.

As for adding more viewing options to the revision view, well, they are handy when they are needed, especially the cross copy history option (i.e. the follow copy operations, see below). The same can be said for the changeset options: you don't change so often the ignore case differences, but I can imagine that this might be useful for some people (actually I never had a need for that myself).

I plan to add an alternative Changelog format to the revision view, and in that case it will be quite useful to first view the revision log, see the appropriate from and to revisions, then regenerate that interval and finally get the changelog you're interested in.

about the choice of Follow copy operation option

A final note: In order to stop the revision log at the first copy operation, I had to use the option name Follow copy operations, defaulted to not checked, instead of using Stop on copy defaulted to checked. This is because from the GET, there's apparently no difference between:

• not checked, in the case you would explicitely mean you don't want to stop on copy
• the situation where the parameter is not set, like when you go to the Revision Log page without any parameter, in which case you want to have the default behavior to stop on copy

In both cases, you would get None. Therefore, the default had to match the unchecked case.

[Christian Boos]

Ok, I think that now there's a simpler and satifying implementation of that feature in [1635]:

• the Older Revisions link remains
• the Newer Revisions link is gone
• you can also restart the revision log at any of the listed revisions by clicking on the first column of the revision's line