Magnus Manske wrote:
For [[Oxygen]], the first edit logged in the database
is mine,
September 15, *2001*. However, when you click on it:
http://en.wikipedia.org/w/index.php?title=Oxygen&oldid=271622
be surprised to find a link to "older version", pointing to an edit
from September 2, *2002*:
http://en.wikipedia.org/w/index.php?title=Oxygen&direction=prev&old…
When you keep following the "older version" trail, you'll end up at
the conversion script edit of February 12, *2002*:
http://en.wikipedia.org/w/index.php?title=Oxygen&direction=prev&old…
I vaguely remember a version-order bug from ancient times. Is that the same one?
Timestamps have one-second resolution and so are not unique. So ordering
by timestamp, "SELECT rev_id FROM revision WHERE rev_timestamp<$t ORDER BY
rev_timestamp DESC LIMIT 1" to find a previous revision introduces bugs,
because faced with non-unique timestamps, it would skip revisions. This is
the algorithm used by the prev/next links on the history page.
Another way to find a previous revision is to order by rev_id. But rev_id
is not monotonic with respect to time, due to various accidents of
history. There are step discontinuities, such as those introduced by
undeletion or the conversion script. It is however used by the older/newer
links on the old revision views. This algorithm is chosen over the
timestamp algorithm because at the time the revision is fetched, the
timestamp is not known, only the rev_id is known. Finding out the
timestamp would require an extra query.
Neither rev_timestamp nor rev_id provides a way to order revisions
precisely. The way to do it properly is to use the rev_id only to resolve
conflicts when multiple revisions share the requested page/timestamp pair.
Unfortunately this is slower and more complex than either of the other two
methods.
-- Tim Starling