minorityreport wrote:

Test on English Wikipedia: 1 Create redlink

Attached:

minorityreport wrote:

Test on English Wikipedia: 2 Create first version

Attached:

minorityreport wrote:

Test on English Wikipedia: 3 Create second version

Attached:

minorityreport wrote:

Test on English Wikipedia: 4 Delete page

Attached:

minorityreport wrote:

Test on English Wikipedia: 5 Restore original version only

Attached:

minorityreport wrote:

Test on English Wikipedia: 6 Both versions are in the history list

Attached:

minorityreport wrote:

Test on English Wikipedia: 7 Clicking the latest version gives error message

Attached:

minorityreport wrote:

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.

minorityreport wrote:

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.