On 17 mrt 2011,at 14:34 John wrote:
On Thu, Mar 17, 2011 at 9:02 AM, Mihajlo Andjelkovic <michael.angelkovich(a)gmail.com
Today I did some analysis over
latest revisions on huwiki and there I
stumbled on something that surprised me. I believed that revids were
given sequentially, so that lower revision id implies an earlier date,
and higher revision id implies a later date. Thus, all edits having id
greater than 6.000.000 would be no older than august 2009 on huwiki.
However, the following revids are anomalies to this, being set 5-6
years back in comparison to their surrounding revids:
I don't really want to ask anything, I hope I pointed out something
interesting. However, if there be any comments on this, shot away. :)
Importing and some deletion related things (before
rev_id was moved
to the archive table) can cause
a revision to get a higher rev_id than it should have
Although 'should' is a relative and questionable word, I just want to
point out that this
is valid and expected behaviour, not a bug.
Revision-ids are assigned in order of which they enter the database
table of public
If I import a page from a different wiki it will get a fresh revision
id, not the same id it had on the old wiki.
Simply because the id it had on the old wiki is most likely already
used on the new wiki.
There is no rule nor any intention to make the ids represent a
timeline, there is the rev_timestamp
column for that purpose.
Another way, as John pointed out, is deletion.
If a page (or rather, it's revisions) are deleted by an
administrator / user with 'sysop' right it will be moved
from revision-table to archive-table.
As of MediaWiki version 1.5 (released in 2005) during deletion /
undeletion the revision-id will be saved
when it's moved to the archive-table, and will be re-used during
undeletion / restore.
So any page deleted after June 2005 will retain the same low old
revision if when restored. However any
page deleted before 2005 didn't have the saved revision-id, so when
any of those pages are restored
now MediaWiki generates a new revision-id, just like it does for
Import, just like it did before 2005 for undeletion.
As we can see in the logs here:
.. that page was deleted before June 2005 and undeleted in 2010.
As such it got a new revision id.
Conclusion: revision.rev_id is great to count revisions, and
contributions. And for developers to see if a revision
was added later in. However it's not meant for timelines, use