On this whole revid vs. timestamp thing: I think I read something a
while ago (don't remember where) about adding rev_previd and rev_nextid
fields, each pointing to the previous/next revision ID (unless of course
it doesn't exist, in which case it would be NULL; does MySQL distinguish
between NULL and 0, anyway?). This would make the prev/next links less
expensive to generate (only one DB query rather than 3), but would cause
an extra UPDATE when adding revisions; also, merging histories could
become a nightmare: in a worst-case scenario, merging N revisions into a
history of 2N revisions would cause all rows to be changed (3 times as
many as is currently the case). Also, filling these fields for existing
revisions would be a huge operation (maybe this could be done on the fly?).
Thoughts?
Roan Kattouw (Catrope)