Edgewall Software

Changes between Initial Version and Version 3 of Ticket #2053


Ignore:
Timestamp:
Sep 13, 2005, 5:19:24 PM (19 years ago)
Author:
Christian Boos
Comment:

When I proposed ?offset=+/-i, I was thinking of the possibility to add links like "-1000 -100 -10 -1 +1 +10 +100 +1000" to jump around in the history with big and bigger steps…

In the meantime, I discussed with cmlenz the possibility of changing the implementation of next_rev, prev_rev and such to make them more efficient, so the offset thing will not be necessary, if the reimplementation succeeds.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #2053 – Description

    initial v3  
    1 Would be nice to expand on [2239] and former svn_authz work so changeset browsing would be more usable. As "Next Changeset" and "Previous Changeset" links can point to changeset where current user will get Permission Denied when clicked, it would be good do do one of few possible things.
     1Would be nice to expand on [2239] and former svn_authz work so changeset browsing would be more usable. As ''Next Changeset'' and ''Previous Changeset'' links can point to changeset where current user will get Permission Denied when clicked, it would be good do do one of few possible things.
    22
    33 * To calculate, while rendering changeset nr. XYZ, what is next and previous changeset current user can see, and create links accordingly. This can be expensive, and done in vain especially if it's true that most users won't surf changesets that way;
    4  * To create these two link as "relative" to current changeset. Maybe only ".../changeset/(next|previous" pair, if referer field is relable, or "../changeset/XYZ/(next/previous)" if it's not reliable. That way, next and prev would be calculated only when (and if) needed. Time spent calculating access would be same, just spent better, as if user clicks through next (or prev) until he gets to visible changeset. All other resource spending involved in that "chain" clicking" would not be needed.
     4 * To create these two link as "relative" to current changeset. Maybe only `.../changeset/(next|previous)` pair, if referer field is relable, or `../changeset/XYZ/(next/previous)` if it's not reliable. That way, next and prev would be calculated only when (and if) needed. Time spent calculating access would be same, just spent better, as if user clicks through next (or prev) until he gets to visible changeset. All other resource spending involved in that "chain" clicking" would not be needed.
    55
    66  Other possibility is to make some other ordering scheme for changesets, but (IMO) with isolation of projects inside bigger svn repos, simple next/prev is all ordering we need. With this enhancement done, we can make many smaller projects running of big svn repos, and still have no interferences at all.