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. From IRC: 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. Additionally note: * 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 cached. 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.
