Roan Kattouw wrote:
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?).
There's been occasional talk, and at one point some code went in and I
think got taken back out temporarily.
One thing to consider is that we could actually *indicate* those
non-contiguous merged sections in some useful way, like a (shudder) tree
view....... maybe.... sort of. :D
Everything gets horrifyingly ugly when you try to do anything other than
straight timelines, though.
-- brion