Re: [grubstreet] Revision history

[prev] [thread] [next] [lurker] [Date index for 2003/1/22]

I just skimmed the source quickly now; the config variable seems to be
$KeepDays, which defaults to 14.  The sub that does the expiring looks
to be ExpireKeepFile().  But I don't hack usemod, that's your and
Earle's department :)

> CGI::Wiki presents a way of addressing this fully. I gather that revision 
> history is not yet implemented, but is planned for.

Revision history is in there.  From perldoc CGI::Wiki::Store::Database
(I really need to tidy up the docs):

       retrieve_node
             my $content = $store->retrieve_node($node);

             # Or get additional meta-data too.
             my %node = $store->retrieve_node("HomePage");
             print "Current Version: " . $node{version};

             # Or get an earlier version:
             my %node = $store->retrieve_node(name    => "HomePage",
                                              version => 2 );
             print $node{content};

           In scalar context, returns the current (raw Wiki language) contents
           of the specified node. In list context, returns a hash containing
           the contents of the node plus metadata: last_modified, version,
           checksum.

           The node parameter is mandatory. The version parameter is optional
           and defaults to the newest version. If the node hasn't been created
           yet, it is considered to exist but be empty (this behaviour might
           change).

I might add a diffing thing soon, although you can do that in script.

> I feel that Grubstreet should keep everything (unless you are an
> admin, in which case you have unrecorded delete and rename functions
> available).

I agree.  CGI::Wiki currently doesn't do any deleting of old versions.

> Here are my thoughts on the subject. What we want could be implemented in 
> several ways.
> 
> 1. A table of page revisions. A special view presents the current revision 
> only, and this view is what is used for the majority of functions.

I don't think all databases support views sensibly.  I've not used views in
anything but ingres, but that doesn't mean they're not there, it means I
didn't look :)

> 2. Abandon using a database to store the wiki text, just use it to store the 
> admin data. Use a version control system (VCS) to hold the text.

Nothing to stop you writing CGI::Wiki::Store::VCS - check the docs for
CGI::Wiki::Store::* to see what the storage backends need to be able
to do.  (Also consider how you're going to implement metadata and
searching for a VCS backend.)

> 3. A table of current revisions. Another table holds patches for historic 
> revisions.
> 
> 4. A table of wiki pages, which contains the revision history.

At the moment the Database stores work as a kind of cross between
these, one table with the latest version of each page and another with
all versions ever.  I don't really like it like this and it will
change at some point.  Apart from anything else it would save on disk
space to just store diffs.  There are also going to be tables to store
metadata.

> 5. Perhaps we don't need to make this decision now, once we have defined the 
> common interface for revision history, then we decide how to implement it.

But I think this is the most important point - with a fixed API that
the stores have to conform to it really doesn't matter what they're
doing internally.  The only difference you see is in how you can
examine and access the data *externally* from the wiki and the
modules.  People who can't install a database or VCS server can use
the SQLite backend with DBD::SQLite in a private directory[0]; people who
want to be able to look at the data in a VCS-y way can use the
hypothetical VCS backend (note I'm probably not going to write a VCS
backend, it's not my itch).

I want there to be lots of ways of doing it, and the best way for you
to be sure that your favourite way will be supported is to send code.


Kake
[0] As I'm doing with the grubstreet clone - I've not got root on the machine.

-- 
grubstreet mailing list
http://london.openguides.org/old-list-archives/

• [grubstreet] Revision history Ivor Williams 14:16 on 22 Jan 2003
  It may be possible to tune or disable this forgetting with config params, but
  • Re: [grubstreet] Revision history Kate L Pugh 17:16 on 22 Jan 2003
    I just skimmed the source quickly now; the config variable seems to be

Archive generated by mariachi 0.51.