Storing node revision history

[BUU]

(Since everyone else was posting discussions I just had to join the flock. woo. Also I'm a dirty xp whore)

Inspired by several recent discussions and being unable to find anything on this subject before (I'm sure it's there but I have no idea what search terms I should have used, but I couldn't find any) I wanted to ask, why doesn't perlmonks do so?

Just spending 5 minutes thinking about it, I would think the easiest way to add this would be special "markup" in the node body, since I assume the body is stored as a chunk in the database someplace, you would simply have the multiple revisions delimited by something, then by default the 'get node' func would only return the last one, but if you pass it a param it would return a different chunk. Then whenever an edit was 'submitted' it would jsut tack another section on to the end. This obviously isn't an optimal solution of course, but it seems simple enough to be easily integrated in to the current perlmonk setup without adding undue server strain/load.

Theres my sort of thought out ideas on implementation, so what are the other reasons for not having it? Social ones? A technical one I'm overlooking?

[grinder]

The database is already under heavy load. The fine art of database retrieval involves getting the database to do as much as possible, in order to return as little as possible. It's therefor somewhat counter-productive to ask a database to fetch a somewhat lengthy string of bytes only to then reprocess it in order to use the last bit.

Theoretically, one would add a new table that contains the node_id, revision tuple and fetch the latest revision with select max(node_id), revision from latest_node_revision with a join on the node_id from some other table.

Pratically, that might be a net loss. It might be better to store revisions in the existing node contents. That would require significant reworking of the existing code to make sure it reprocessed the node contents to only pull out the last revision. Down that path lies madness. (Although if I had to envisage doing such a thing in other circumstances, I would encode the different chunks as MIME entities rather than reinvent that particular wheel).

I'm also pretty sure that nodes have a hard upper limit of 64kb. Storing multiple revisions of lengthy nodes would quickly blow past that limit. All other things being equal, a lengthy node is also more likely to be tweaked.

My feeling is that thepen's Perl Monk Archive is sufficient to get the (approximately) original view of the node. And if someone really wants to wipe out the contents of their nodes, these can always be restored from tape (this has happened before, with mt2k and tye in the roles of reaper and restorer).

[CombatSquirrel]

You often see ("often" depends on your point of view) relatively long (also depends on your point of view ;-)) post with short updates like "changed ~= to =~, thanks to ...". If you store every instance of the node, the data would grow pretty quickly. Maybe diff would be a soulution, but I think there's always the problem with the available disk space.
Cheers,
CombatSquirrel.

---

Entropy is the tendency of everything going to hell.

[pg]

Within 2 days, we had a stream of discussions about this. To be frank, I am really really tired of this.

Let's forget about the XP points, and ask ourselves the question why do we come here and why others come? Ultimately we all come to talk about Perl, share Perl knowledge, anything that's beyond this is not important at all. We call this a forum, so the more freedom monks get, the better. Let the community adjust itself, not use any single person's power (or a small group of persons' power) to adjust it. Let's have trust in our little cyber community.

[theorbtwo]

There's a better way to implement this. Much better, and already mostly done. My previous remarks about db load and such are wrong. There's a device called the "editor's history" that shows the history of changes by editors. I think we should make all edits show up on that history, and make it visible to all.

Cons: more db use, there's no way for editors to hide things without additional effort/code. Non-cons: no additional overhead per view. Very little new code to write. Editors can't hide things without additional effort/code (yes, that is both). (The pros are obvious. The non-cons above are more of non-issues -- things which may appear to be pros or cons, but are in fact no different from the current state.)

As to taking up more db space, the current implementation of this featuere is hugely innefficent. Each edit stores the complete pre/post state. The poststate is redundant -- it is the same as the prestate of the next edit, or in the case of the last edit, the current node (which has sepperate storage). Additionaly, for most edits, most of the content is unchanged. Storing a diff instead of the prestate would alleviate this, and diff -u is easy enough to process (if edits should be reversed), or simply read.

(There is a similar innefficency in the patch system, bu it isn't as bad, and is a less important system.)

[CountZero]

The main reason for not having it, is IMHO that the Monastery at large is not really much bothered by the few edits done to original nodes (the infamous disappearing root nodes which makes the rest of the discussion rather Kafkaesque). If I may suggest, perhaps it is a good idea for a poll, just to see how many monks are bothered and wish to have a versioning system installed on the Monastery.

[Anonymous Monk]

One reason for not having it is that most nodes should not be edited (i'm excluding tutorials, code catacombs, snippets).

This is not a wiki.