WikiPatches/PermanentRevisionHistory

This patch adds a new false setting to $KeepDays? to prevent old revisions pages from being expired. If you set $KeepDays? to either "" or 0 then no revisions will expire.

--- wiki.pl     Sat Apr 21 19:44:10 2001
+++ newwiki.pl  Mon Feb 17 16:55:53 2003
@@ -69,6 +69,7 @@
 $RcDefault   = 30;              # Default number of RecentChanges days
 @RcDays      = qw(1 3 7 30 90); # Days for links on RecentChanges
 $KeepDays    = 14;              # Days to keep old revisions
+                                # 0 = keep all revisions;
 $SiteBase    = "";              # Full URL for <BASE> header
 $FullUrl     = "";              # Set if the auto-detected URL is wrong
 $RedirType   = 1;               # 1 = CGI.pm, 2 = script, 3 = no redirect
@@ -1860,6 +1861,8 @@
   my ($fname, $data, @kplist, %tempSection, $expirets);
   my ($anyExpire, $anyKeep, $expire, %keepFlag, $sectName, $sectRev);
   my ($oldMajor, $oldAuthor);
+
+  return unless $KeepDays; # PATCH PermanentRevisionHistory

   $fname = &KeepFileName();
   return  if (!(-f $fname));

-- JoshJore?

---

 +  return unless '$KeepFile'; # PATCH PermanentRevisionHistory

should be

 +  return unless '$KeepDays'; # PATCH PermanentRevisionHistory

-- Johnson

---

Does this create a performance hit over time? I am not clear about how it is architected. -- ChrisBurbridge

First of all, my recommendation is simply to set $KeepDays? to a large number like 20000 days, and remember to rewrite the software sometime in the next 50+ years. :-)

It could create a performance problem eventually, or even make the script crash if memory or CPU time is limited. Problems should be limited to large frequently-edited pages, however. There might be problems displaying history for a huge number of versions--many browsers will not handle radio-buttons with 1000+ choices very well.

The basic "architecture" of the keep files (used for revision history) is that they are simply sequential dumps of the .db file contents, separated by a special $FS character sequence. The entire keep file is read into memory when it is used, and then it is split into individual revisions. This means that the script uses at at least (2 * size-of-keep-file) bytes of memory whenever a page is edited or non-cached diffs are displayed. (In 1.0 there is a setting to limit the maximum size of a keep file--this was required for MeatballWiki.)

Finally, the "keep file" system is one of the ugliest parts of UseModWiki's design, and I am not very happy with it. Still, it works reasonably well for most users. --CliffordAdams

---

Regarding to order to Permanent Revision History in order to doesn't compromise the resources, you can always hack the code adding in data dir, other subdirectory and there, grab separate versions of revisions. For instance:

$PermaDir     = "$DataDir/perma";     # Stores permanent kept (old) page data

architected database as

sub CreatePermaFile {
  my ($path, $dir) = @_;

  &CreateDir($path);
  if ($dir =~ m|([^/]+)/|) {
    $path .= "/" . $1 . "/" . $Page{'revision'}.'kp'; # (or  $path .= "/" . $1 . "/" . ($Page{'revision'} % 10) . "/" . $Page{'revision'}.'kp';)
    $dir =~ s/([^\/]+)\///;
    &CreatePermaFile($path,$dir);
  }
}

sub CreatePermaDir {
  my ($dir, $id) = @_;
  my $subdir;

  &CreateDir($dir);  # Make sure main page exists
  $subdir = $dir . "/" . &GetPageDirectory($id);
  &CreateDir($subdir);
  $subdir = $dir . "/" . &GetPageDirectory($id) .  "/" . $id;
  &CreateDir($subdir); # (if or: $subdir = $dir . "/" . &GetPageDirectory($id) .  "/" . $id .  "/" . ($Page{'revision'} % 10);)
  &CreatePermaFile($subdir,$id);
}

--JuanmaMP