Tags:
create new tag
, view all tags

Feature Proposal: Limit or Make Configurable the number of revisions shown in History results

Motivation

The current version of TWiki (v4.1.2) returns EVERY revision when you click the History link at the bottom of a topic. For topics with hundreds of revisions it can take a LONG time for TWiki/rcs to construct the revision history, and it can produce a HUGE page.

Description and Documentation

The old version of TWiki (v2.x???) only returned the last 10 revisions of any topic's revision history, so it always loaded quickly. We then had the option on the results page to see more. I would like to see this functionality return. I'm aware that in the current TWiki we can construct a URL with something like "?rev1=100;rev2=90", but but doing so is cumbersome, and less than obvious to end users. The enhancenment, then, is to give the TWiki administrator a configurable option to set how many revisions are returned by the History link; the default, if the option is not set, should be 10, I'd think.

  • I think that the functionality of HistoryPlugin and CompareRevisionsAddOn should be integrated into the Core. This 'Limit' should be used as a trigger to revisit the code - when I implemented it in Cairo, I wrote it to be pluggable and extendable. Unfortuanatly, no-one's done much work on it since. -- SvenDowideit - 15 Dec 2007

Examples

Impact

WhatDoesItAffect: Performance, Prefs, Rendering, Usability

Implementation

-- Contributors: BarryLake - 06 Dec 2007

Discussion

This is a good idea IMHO, which I guess could be handled in the skin (generate the rev numbers for the History button?)

-- CrawfordCurrie - 07 Dec 2007

You got my vote as well.

-- CarloSchulz - 07 Dec 2007

How can we construct such urls in a template?

-- ArthurClemens - 07 Dec 2007

Good idea indeed.

It could be done with a spreadsheet formula that calculates the range based on the top rev. But since the core already now build the links of the last few revs and also for performance reasons, I suggest to to do that in the core. So, instead of parameters rev1=36;rev2=26 you would have rev1=36;rev2=-10. The negative number indicates a relative rev number compared to the first one.

In addition, the history page should have some control over the displayed revs, so that it is possible for example to click on the history to get the last 10 revs, and then click on another link in the history to see the next 10 revs or a bigger range.

-- PeterThoeny - 07 Dec 2007

Peter, the History link doesn't include revision parameters like rev1=36;rev2=26. It looks like this http://my.site.com/twiki/bin/rdiff/Myweb/MyTopic?type=history. So the parameter "history" appears to be passed to the lib/TWiki/UI/RDiff.pm program, which then expands it into the appropriate revision range, and its current behavior, of course, is to return the entire range.

For what it's worth, I just installed the following brute force hack into the RDiff.pm program (in my TWiki) on or around line 439:

    $rev2 = $session->{store}->cleanUpRevID( $rev2 );
    $rev2 = $rev1-10 if( $rev2 < 1 );                    <<== This is the new line
    $rev2 = 1 if( $rev2 < 1 );
    $rev2 = $maxrev if( $rev2 > $maxrev );
I'm aware that the resulting history page doesn't give me any easy options to see additional revisions beyond the most recent 10, as that would require a change to the template, which is beyond me. But this hack accomplishes what I want for now, and I can live with its deficiencies. I look forward to this being done right, and I'm gratified that folks seem to like the suggestion.

-- BarryLake - 07 Dec 2007

Instead of repairing the rdiff (history) I would propose to integrate the function of the HistoryPlugin in the core. Either by adding the plugin or by doing an actual integration in the core. The HistoryPlugin gives a function very similar to what is known from Wikipedia.

I just updated the HistoryPlugin this weekend so it works both with 4.1 and the 4.2 we are about to release and in combination with CompareRevisionsAddOn.

And talking about that I also think that CompareRevisionsAddOn should be integrated and replacing the rdiff we have today. It is far superior in every respect.

Barry you should look at the HistoryPlugin.

To see it in real life see http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome and hit the History link at the bottom.

It gives the limitation you want and a much better user interface. I also have CompareRevisionsAddOn installed.

-- KennethLavrsen - 10 Dec 2007

Kenneth, thanks for the info about the HistoryPlugin and CompareRevisionsAddOn plugins. It all does look very interesting, and I think there's certainly room for improvement in TWiki's default History mechanism, which might benefit from some of the ideas in those plugins, especially the CompareRevisionsAddOn plugin.

But I don't like all the extra work I have to do when using the HistoryPlugin. I ususally just want to click History and take a quick peak at recent changes. Using the HistoryPlugin I have to click my desired starting and ending revisions, and then click compare... that's three extra clicks just to see recent revisions. It may not sound like a lot, but it is extra work, and it detracts from the streamlined usability I think we're all striving for in our web sites.

In general, we have to weigh in balance the promise of extra functionality and features with the concerns of basic usability and elegant simplicity. The HistoryPlugin goes too far in the direction of the former at the expense of the latter, IMHO.

-- BarryLake - 10 Dec 2007

Hmm. You are actually right. I may in a near future consider if the first and last of the up to 10 (default) versions shown should be selected by default. That saves the two clicks in 90% of the time.

Normally I look at the change between current and previous version by clicking the small "<" directly on the action bar. That is one click. And that covers my need in 95% of the time. The last 5 I normally want to select exactly which versions to compare based on the info I see in the HistoryPlugin. If you use TWiki 4.0.3 and forward all you need to do to try HistoryPlugin is install it through configure and activate it in configure and it is active without any further actions or installation. If you do not like it it can be deactivated in configure and it is in practical gone. So it is fast to give it a try.

I will look at how easy it is to add the default selected versions. Is 10 the right number or should the default be 5 versions back and latest?

-- KennethLavrsen - 10 Dec 2007

I'm used to the way the old TWiki did it (which is why I opened this topic!), and it always showed the 10 most recent revisions. But if you believe 5 is the right number, perhaps due to performance considerations, then I can live with that.

-- BarryLake - 10 Dec 2007

I suggest to implement this feature for performance reasons, regardless if we decide to add the HistoryPlugin later. Mini-spec:

  • Clicking on "History" link shows 10 latest revs in diff page
  • Diff page has selectors to select range and/or prev/next links

-- PeterThoeny - 12 Dec 2007

Hi, I just updated my TWiki from version 4.1.2 to 4.2.4 and notice that this feature has still not been incorporated, so I had to install my "brute force hack" again. Any idea if or when this will be added? Thanks!

-- BarryLake - 13 Mar 2009

Ping on this useful feature. Anybody interested in driving a clean implementation?

  • Clicking on "History" link shows 10 latest revs in diff page
  • Diff page has prev/next links & page links like in WebChanges

-- Peter Thoeny - 2013-11-15

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2013-11-15 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.