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