[pmwiki-users] RFC: Limit the number of displayed diffs at once
5ko at free.fr
Wed Apr 19 02:33:43 CDT 2006
On Saturday 15 April 2006 13:20, J. Meijer wrote:
> I took a look at you contribution at
> And it seems like a feature worth having to me.
> For sites which maintain all page history a page numbering scheme would be
> appropriate, to allow direct selection of a page from the history.
> Alternatively the new summary field could be used to make an outline of the
> diff. Then actual changes (the current diff) would be shown after clicking,
> redirecting to a diff subset or using an immediate inpage expand (show/hide
Thank you for your comments. This feature exists in other wikis, MediaWiki,
Wakka & clones, etc., but they have completely different storage principle
(they store all revisions and do a diff on user demand) than PmWiki (does a
diff when saving a new version.
The first principle has some advantages, that is, easier to request any
version, even thousands of revisions ago, for review and/or edit, and also
easier to do a diff between any arbitrary two revisions, even
This principle, or something similar, may be done with a big change on the
PmWiki code, so it is better to try to write a Cookbook extension, eventually
defining a new action.
The second, PmWiki principle, has the advantage of smaller data size as only
diffs are stored (that is, if the wiki has not much vandalism), and the
possibility to view several diffs between revisions at one page.
A disadvantage, as I see it, is that pages with very large history may be
difficult to load in some browsers, if the full history is requested. With
5-10 cases of blanking vandalism and reverting, the "history" page grows
10-20 times the actual page.
That's why I modified the function (PITS/00544) to display a limited number of
diffs per page. It is really easy to implement it without a major
disadvantage considering the current PmWiki behaviour. That is why I feel it
is reasonable CoreCandidate too.
More information about the pmwiki-users