next/previous changeset links to take in account svn_authz permissions

[dragisha@…]

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.

• 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;
• 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.

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.

[cboos]

Bingo! ../changeset/XYZ/(next/previous) is a great idea.

I'd rather have the URL set to ../changeset/XYZ?offset=+/-i,
as it's more general and won't interfere with the
restricted changeset syntax used in TracDiff
(i.e. ../changeset/XYZ/trunk/path for browsing
the changes located below a given path).

I'll experiment with that idea in TracDiff, as I have
exactly the same need there, when looking at the next change
for a restricted changeset (I didn't even provide the
Next Change link so far, for the reason you describe).

If that works fine, I think we should use that as a replacement
for the need of the history array in SubversionRepository,
which is quite an expensive thing to compute at every request,
for big repositories.

[dragisha@…]

I don't see offset=+/-i point there, as "three changes ago in set visible by me" is not something I can comprehend, but if implementation cost is same as for simple next/previous, then why not :). As far as we get this subsetting of changesets, and elegant trac-ing of multiple projects from single svn repo, it's ok.

[cboos]

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.

[cboos]

I believe that since the TracDiff integration (trunk r2808),
this should work as expected (not only for changesets,
but also for restricted changesets)

Please reopen if this is not the case.

[cboos]

There are performance issue though, see #6654.