Last modified: 2010-05-15 15:37:50 UTC
This has been confirmed on live Wikipedia. (27 Jul, 2005).
Create an article.
Edit so you have two versions.
Delete all versions.
Undelete the original version only.
Undelete the latest version.
The original version is restored correctly but the latest version vanishes.
In a test on a modified 1.4.7 database, the version was deleted from archive but
was restored to old instead of cur. The version in cur should have been moved
to old and the restored version should have been moved to cur.
Created attachment 744 [details]
Test on English Wikipedia: 1 Create redlink
Created attachment 745 [details]
Test on English Wikipedia: 2 Create first version
Created attachment 746 [details]
Test on English Wikipedia: 3 Create second version
Created attachment 747 [details]
Test on English Wikipedia: 4 Delete page
Created attachment 748 [details]
Test on English Wikipedia: 5 Restore original version only
Created attachment 749 [details]
Test on English Wikipedia: 6 Both versions are in the history list
Created attachment 750 [details]
Test on English Wikipedia: 7 Clicking the latest version gives error message
The behavior above was largely due to buggy caching. Turning off caching in
preferences, I was able to see the history correctly restore the latest deleted
version. However the older version was still displayed as the latest version,
even though the page history correctly showed the newer version and gave full
access to it.
Tony_Sidaway A lot of the bug I was seeing before was just page caching.
Tony_Sidaway I still get a problem though. I'll update the bug report.
Okay, two bugs. (1) page caching is a heap of poo when you do this kind of
thing. (2) now I disabled caching and then undeleted the newer version, my older
version is stil being displayed as the latest, although the hisitory list is okay.
So it goes like this: Create A, edit to make B. Delete article, A and B.
Undelete A only. Undelete B. Now the history is correct but A instead of B is
displayed as the latest version (and it doesn't seem to be browser caching either).
And it's not by ISP's proxy, this is over my own intranet, direct SSL
connection on the LAN.
Before we go into this, let me first detail the changes from 1.4 to 1.5:
* All versions including the current version have a revision id number.
* When a page is deleted, the revision number is stored in the archive table.
* When those revisions are restored, the original revision number is retained.
* When a page is restored when there is a page already present, the 'current version' marker is not necessarily
updated. All revisions are present but the 'current' one may still be what was previously there.
* When a page is restored, the page_touched cache marker is not necessarily updated, so the history view may be
Can you confirm that, given the caveats above about display oddities, the selected revisions are all restored?
If so, this report can be closed. Open new bug reports about the cache issue if there's not already one.
I agree that much of the initial behavior was due to problems with page caching,
and I'm changing this bug because I see no evidence that data is lost in either
HEAD or 1.4.7.
Briefly, the problem I see now is that page.page_latest is not being updated in
1.5 (I'm testing on a branch I made at the weekend) and in 1.4.7 the problem is
that the later version is restored to the "old" table instead of displacing the
earlier version in "cur". The effect in both cases is that the older version of
the page is regarded as current.
In 1.5, the history display is in the correct order by the current version is
the older one.
In 1.4.7, the history display is garbled, with the older version appearing above
the newer one.
This behavior may or may not be considered a bug--it's likely to confuse a lot
of editors, but is not likely to be encountered very often. In any case it is
not urgent because it can be worked around by normal editing. Rather than
completely close it I'm marking it as minor severity, low priority.
I'll review the bug report history for caching and whatnot and may submit a new
bug report or augment an existing one to cover caching behavior.
Restored bug from flood attack.
Done in r21989.