Last modified: 2014-08-04 23:31:57 UTC
See [[mw:User:MZMcBride/Attacks#Merge_page_histories]]: This attack by a rogue sysop "causes a royal mess that very few people can clean up properly. Find two pages with less than 2500 revisions (A and B) and one page with thousands and thousands of revisions (C). Delete page A and move page B to A's old location. Delete page B and then move page C to B's (and A's) old location. Restore the edits and suddenly you've merged three page's history into one. And there's nothing easy to do to reverse it." One solution might be to track in log_search or log_params the revision IDs involved in page move, page deletion, and page undeletion events. Then a non-rogue sysop could select the log events to roll back, and the pages could be restored to their condition before those log events occurred.
Wasn't there some plan once Special:MergeHistory was better developed to disable history-merging-via-undelete? Maybe I'm misremembering.
The difficult-to-undo damage occurs when the deleted revisions are restored and thus merged, though the same effect arises when revisions are deleted (that is, revisions become merged in the history of deleted revisions). This is one of a class of problems where a single command actually performs many actions that are not reversible with a single command, an "undo." Page moves including subpages can show a similar issue, I found to my regret when I once moved a page and included subpages without checking, and there were hundreds of them and then the move turned out to be a Bad Idea.
(In reply to Abd ulRahman Lomax from comment #2) > The difficult-to-undo damage occurs when the deleted revisions are restored > and thus merged, though the same effect arises when revisions are deleted > (that is, revisions become merged in the history of deleted revisions). This > is one of a class of problems where a single command actually performs many > actions that are not reversible with a single command, an "undo." Page moves > including subpages can show a similar issue, I found to my regret when I > once moved a page and included subpages without checking, and there were > hundreds of them and then the move turned out to be a Bad Idea. It's not so much when the pages are deleted that the problem arises, as when they're undeleted. When they're deleted, the revisions get moved from the revision table to the archive table, where it's possible to tell which pages they came from by the [[mw:Manual:Archive table#ar_page_id]]. When they're undeleted, they get moved back to the revision table, and they all end up with the same [[mw:Manual:Revision table#rev_page]] if they're being undeleted to the same page title.
(In reply to Bawolff (Brian Wolff) from comment #1) > Wasn't there some plan once Special:MergeHistory was better developed to > disable history-merging-via-undelete? Maybe I'm misremembering. I hadn't heard of that. I wonder how that would be implemented? E.g., perhaps it would be disallowed to undelete revisions with different ar_page_id values in one undelete action, and/or it would be disallowed to undelete revisions to a page that already exists?
Proof of concept for (one possible way of) reversing these attacks is [[Extension:MoveRevisions]].
Er, [[mw:Extension:MoveRevisions]], rather.
