Renamed files and prev/next links don't work well

[Martin.vGagern@…]

source:trunk/trac/versioncontrol/web_ui/browser.py@10924#L427​ creates links for the previous, next and latest revision of a given file. This does not take name changes into account: the link will always be for the created_path member value, which is described in #3340. But in the presence of a rename, both the preceding and the next revision of a file might be in a different location.

So Repository.previous_rev and next_rev should probably be allowed to not only return a revision but a new path as well. Perhaps you could allow them to return a tuple, either checking the actually returned value using isinstance or breaking backwards compatibility. Or you could introduce a new method. Up to you. Current api at source:trunk/trac/versioncontrol/api.py@11059#L873​ Perhaps this would help getting rid of created_path altogether, as it would now be up to the repository backend to decide what path to return.

[Christian Boos]

Right, we probably need something like previous_node, next_node, returning lists. But we have to be careful about the performance here.

The current implementation is already a performance killer (#8813, ticket:8519#comment:5).

[Martin.vGagern@…]

It's a waste of performance to recompute the values for these links whenever people view a file in the browser. But if people want to navigate between revisions, a powerful user interface would be very nice. So how about the following:

• Set up dedicated URLs to represent the prev, next and possibly also up links
• Provide a hook so vcs backends can suppress those links in cases where they know (without too much of a performance penalty) that there are no matching revisions.
• Only when a user clicks on the link, have the backend compute the corresponding data.
• If there is only one matching revision, directly go to it. Otherwise, give the user an opportunity to select from the alternatives.
• Integrate this nicely with the UI: have the href of the link point to a page which either displays the list or does the redirect, but if AJAX is available, use that to show a pop-up instead, if one is required.

This approach would get rid of the common-case performance penalty, at the cost of one HTTP round-trip in cases where a user actually follows such a link. And for cases with more than one previous or subsequent revision, a more powerful UI could make all the data in the repository available to the users as well.

Perhaps it would be best to have all of the new functionality be part of the Node interface, instead of the Repository interface. That way, backends could cache additional data in that object without having to cache the node object itself for re-use by the repository request.