This sounds like a good idea, as long as it's possible to display 50 or 100 edits at a time for enormous histories, and it's possible to select all edits besides one or two (like the invert selection button). I assume that the edits that are left behind would be placed in the archive table so they wouldn't clutter the page history.

I always use selective undeletion for history merges, so this wouldn't entireley supercede the selective undeletion feature. With my method, where A is the current title of the page and b is the one with the edits that need to be merged, I history merge like this: move page A to page B (Page B is deleted to make way for the page move), undelete old content edits of B, move B back to A, undelete remaining redirect edits of B. Maybe I'm over-fussy, but I don't like adding irrelevant redirect edits to an article's page history.

FT2.wiki wrote:

Minor clarification: if this function existed, then one could package all the deletion tools and resolve bug 21279 by simply making the problem never arise:

1/ Add RevisionDelete
2/ Add RevisionMove
3/ Prevent selective undelete (only allow full delete/full restore)
4/ Prevent RevisionDelete or RevisionMove of deleted revisions (must be undeleted first)

Effects/results:

1/ Any redaction would need to be done by RevDelete not traditional "vanishing" of a revision (and undeleting then redacting if it was a deleted revision)
2/ Any page merge or copy/paste fix would need to be done using RevisionMove not traditional delete
3/ Traditional delete exists, but only to delete/undelete full pages
4/ Traditional partial delete (ie full delete + partial restore) is phased out by making it impossible; one can only delete to fully delete or fully restore a page, anything else must be done by RevDelete redaction, or RevisionMove)
5/ All traditional uses of deletion are still fully available, but traditonal partial delete becomes deprecated/redundant/historic, and RevDelete never needs to be used (or able to be used) on a deleted revision, which fixes bug 21279.

As long as the logging is good, this would also have the effect of making history merges a lot more reversible than now.

3/ Prevent selective undelete (only allow full delete/full restore)

What about copyvios? What about people who just want to clear the history of their userpage?

I think we should still allow selective undeletion.

(In reply to comment #4)

3/ Prevent selective undelete (only allow full delete/full restore)

What about copyvios?

These can be deleted using RevisionDelete, if necessary

What about people who just want to clear the history of
their userpage?

I don't see why we need to support this ability. The whole purpose of the page history is to record all the changes that led to the current version. Deleting all but the current revision defeats the purpose of having the history (by deliberately obscuring it), and if anyone but the user made a substantial edit, it could be a license violation.

I think we should still allow selective undeletion.

Nonetheless, disabling selective deletion just seems like unnecessarily limiting choice.

I suppose the ability to disable it on a site-by-site basis could be provided and a discussion be held whether we want to disable it on en.wiki.

FT2.wiki wrote:

(In reply to comment #5)

What about copyvios? What about people who just want
to clear the history of their userpage?

Both are easily handled by RevisionDelete. In the former case the copyvio is placed out of public access completely, and inaccessible to non-admins, but the editor's name is not (it's not a copyvio), nor is the fact there was a deletion. Net benefit.

In the latter case a user who wants to completely delete their user page or talk page can. But a user who wants to selectively remove some material, it's again arguably beneficial that the record shows there were edits there at some point, otherwise the record has actually become falsified; the page history is made to appear as if nothing took place when in fact a great deal may have taken place. Redaction's more honest.

Per comment #5, a site by site on disabling selective deletion would be fine. The problem is that right now selective deletion is breaking links everywhere, badly. Doing this would allow an easy fix to all that, probably _much_ easier than trying to fix major link-breaking bug #21279, while simultaneously improving history merges and copypaste fixes (comment #3) and improving transparency of page histories where selective deletion is traditionally used (comment #5).

That in itself could be compelling, if delete link breakage can't be otherwise easily fixed.

Considering that this bug is inactive for such a long time now, I'm going to be bold and try to fix it.

Here's what I'd like to to:

Create a new special page "Special:RevisionMove", that allows selective move of revisions of a page – for admins only (by default; there will be a new user right), because this can mess up histories pretty badly.
I'm going to try to make it possible to merge Special:MovePage into this (in case we want to do that some distant time in the future).

The UI for selecting revisions would use same as with RevisionDeleting in the page history, with a new button "Move selected revisions". The rest would also look pretty similar to the revision delete page.

Considering the fact that we want to move away from the archive table system, this probably will only work for not-deleted pages.

When moving a set of revisions, the special page has to differentiate between an existing target or a nonexisting one. In the latter case, a new page has to be created.

Any ideas, comments, suggestions?

One problem might be logging of such events. It is not feasible to have a log entry for each individual moved revision, but an entry like "x Revisions have been moved" doesn't tell you *which* revisions were moved.

On the other hand, RevisionDelete has the same problem and there aren't many complaints about that.

But that isn't enabled on WMF wiki's yet...

It is for oversights and stewards.

By imposing permission restrictions, I think we can justify this lack of transparency. Admins can do a lot of nasty stuff, this would just be one of them.

FT2.wiki wrote:

(In reply to comment #9)

One problem might be logging of such events. It is not feasible to have a log
entry for each individual moved revision, but an entry like "x Revisions have
been moved" doesn't tell you *which* revisions were moved.

On the other hand, RevisionDelete has the same problem and there aren't many
complaints about that.

At the risk of proliferating an extra table or an extra field, this is a one-way lookup, from (log action id) -> (list of revisions) or (log action id) -> (html string containing list of revision links). It should not be difficult to have a log entry like:

"User X moved [[LINK | 17 revisions]] from [[article-1]]
to [[article-2]] (REASON)"

or

"User X changed visibility of [[LINK | 17 revisions]] of 
[[article-1]] from OLD-VIS to NEW-VIS (REASON)"

with the link going directly to the revision or revdelete page if one revision was moved, or a hoverable list, or a list of revisions (or a list collapsed on the revdelete page) if more than one was moved.

FT2.wiki wrote:

(In reply to comment #8)

Here's what I'd like to to:
(Snip)
Considering the fact that we want to move away from the archive table system,
this probably will only work for not-deleted pages.

When moving a set of revisions, the special page has to differentiate between
an existing target or a nonexisting one. In the latter case, a new page has to
be created.

Any ideas, comments, suggestions?

1/ Moving only undeleted revisions works and can help keep it clean. If deleted revisions are involved then the deleted revisions can be undeleted, moved, then (if applicable) any deletable content removed using RevisionDelete. I think this is what you meant?

2/ A few "ease of use" suggestions to throw into the mix:

• An "undo this move" button. RevisionMove needs a one click undo, as RevDelete effectively has. People make mistakes and will need to quickly reverse "whatever they just did".

• A "Preserve deletion status?" option that's available if any revisions are deleted. Checking the box means that RevisionMove will undelete these, and revisiondelete them again, to hide the fields specified (or all fields for simplicity), before moving them, with a reason such as "automated conversion from selective delete to revision delete, see (LINK TO REVISIONMOVE ACTION)".

This will be a common sequence in the early days and is easy and useful to automate.

• A confirmation dialog "this target page does not exist, are you sure you wish to create a new page?" will be sensible.

• An "invert" button to specify all revisions except those checked, and usual shift click + ctrl click options. If those don't exist they are useful enough that they should.

Hi FT2, thanks for your feedback.

(In reply to comment #12)

At the risk of proliferating an extra table or an extra field, this is a
one-way lookup, from (log action id) -> (list of revisions) or (log action id)
-> (html string containing list of revision links).

I thought about storing the information *which* revisions have been moved (instead of just the count) somewhere in the DB, and here's why I don't want to do it:

1. Schema changes suck.
2. RevisionMove is a rarely used feature which means

2.1 a schema change only for that minor feature would be controversial
2.2 it isn't really necessary or worth the effort

3. Users who have permissions to move revisions (I suggest admins by default) usually know what they're doing.
4. The current revision move process (delete, partial undelete, move, undelete) allows you to screw up just as bad
5. Other operations that affect multiple revisions don't store exact information about which revisions were affected as well.

(In reply to comment #13)

1/ Moving only undeleted revisions works and can help keep it clean. If deleted
revisions are involved then the deleted revisions can be undeleted, moved, then
(if applicable) any deletable content removed using RevisionDelete. I think
this is what you meant?

Yes.
I was referring to revision which are deleted in the old way (i.e. in the archive table, not in the revision table). I don't want to implement anything for a soon-deprecated deletion schema. RevisionMove won't touch RevisionMove restrictions. There are no special restrictions in moving RevDeleted (even suppressed) revisions.

2/ A few "ease of use" suggestions to throw into the mix:

• An "undo this move" button. RevisionMove needs a one click undo, as RevDelete

effectively has. People make mistakes and will need to quickly reverse
"whatever they just did".

A "undo" link on the success page would be possible. However, an undo link in the log (or something like that) would require saving which revision where moved. That is not going to happen anytime soon, see above.

• A "Preserve deletion status?" option that's available if any revisions are

deleted. Checking the box means that RevisionMove will undelete these, and
revisiondelete them again, to hide the fields specified (or all fields for
simplicity), before moving them, with a reason such as "automated conversion
from selective delete to revision delete, see (LINK TO REVISIONMOVE ACTION)".

Why should RevisionMove change deletion status of revisions? RevisionMove just moves revisions from A to B, nothing more.

• A confirmation dialog "this target page does not exist, are you sure you wish

to create a new page?" will be sensible.

We assume that the admin knows what he is doing. If he accidentally creates a new page, it's trivial to move all the revisions of the new page to the desired target page.

• An "invert" button to specify all revisions except those checked, and usual

shift click + ctrl click options. If those don't exist they are useful enough
that they should.

That would indeed be useful – not only for RevisionMove, but also for RevisionDelete. Note that it would only affect currently displayed revisions (e.g. not the 50 older revisions ;))

FT2.wiki wrote:

I'm not convinced that "It wasn't covered in the past" and "old extensions don't always do it" are good rationales. Surely the eseence of a wiki is to be able to trace who did what, and to improve as time passes. So even if we had not done it in the past, revDelete does attempt to, and I think RevMove should probably attempt to as well. It's good wiki-practice.

A second thought is, RevMove alone is minor, however it parallels RevDelete which isn't, and which does keep a note of revisions acted upon. So there's probably already space to store the data in the db.

Agree that making RevMove only work for non-deleted pages and revisions (including non-deleted revisions with RevDeleted fields) will help to prevent a number of possible issues that would arise if it tried to be usable on "traditional" deleted revisions.

Agree its easier that the admin corrects a creation error, than top be asked each time "are you sure".

Done in r67094. Still experimental.

Test it with the following line on your local test wiki:
$wgGroupPermissions['sysop']['revisionmove'] = true;

FT2.wiki wrote:

Is this available on any WMF test wiki? To see how it works?

This function messes around with the database, so I think the code should be reviewed before it goes live on a public test wiki.
A review would be nice, though :)

And of course you are free to test it on your own (local) wiki.

Re-opened because this bug is technically not resolved (imo) until it's actually available on WMF wikis (at the very least testwiki so it can be reviewed by laypersons who don't run their own wiki...).

Don't mix code issues with site configuration. This bug was for a feature to be developed. It exists now, so this bug should remain closed. All requests to enable it somewhere should be filed separately.

(In reply to comment #20)

Don't mix code issues with site configuration. This bug was for a feature to be
developed. It exists now, so this bug should remain closed. All requests to
enable it somewhere should be filed separately.

It has not been reviewed for the WMF branch - how does one request that?

(In reply to comment #21)

(In reply to comment #20)

Don't mix code issues with site configuration. This bug was for a feature to be
developed. It exists now, so this bug should remain closed. All requests to
enable it somewhere should be filed separately.

It has not been reviewed for the WMF branch - how does one request that?

By doing what Max said above. Open a bug requesting it be enabled on xyz wiki(s), then before it's deployed someone will review it.

The other option is waiting for normal code review + deployment to catch up.

(In reply to comment #22)

(In reply to comment #21)

(In reply to comment #20)

Don't mix code issues with site configuration. This bug was for a feature to be
developed. It exists now, so this bug should remain closed. All requests to
enable it somewhere should be filed separately.

It has not been reviewed for the WMF branch - how does one request that?

By doing what Max said above. Open a bug requesting it be enabled on xyz
wiki(s), then before it's deployed someone will review it.

The other option is waiting for normal code review + deployment to catch up.

Kind of like we did with https://bugzilla.wikimedia.org/show_bug.cgi?id=24157 ?

This was backed out of trunk in r86155.

FT2.wiki wrote:

Comment 20 states "This bug was for a feature to be developed. It exists now, so this bug should remain closed."

But r86155 states it was backed out "until somebody has the time to work on it again".

Are there issues? What has to be done to get any issues related to its backing out resolved, and the code enabled on a test wiki so it can be this reviewed (per r86155 comment) re-added and enabled on a test basis for people to play with?

See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for information on what is needed to get an extension reviewed before potentially deploying it on a wikisite.

unassigning this from myself, I currently don't have time to work on MediaWiki.

In what does this differ from mergehistory?
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56356

(In reply to comment #26)

See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for
information on what is needed to get an extension reviewed before potentially
deploying it on a wikisite.

-> moving to extension requests.

(In reply to comment #28)

In what does this differ from mergehistory?
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56356

This extension would make it possible to separate edits with exactly the same timestamp (see bug 37465) and it would also make it much easier to remove one or two edits in a page containing several thousand revisions like this: http://en.wikipedia.org/wiki/User_talk:Graham87/Archive_18#Unusual_history_merge

Can Mergehistory do that?

Can this be normal priority rather than low? History merges are a regular maintenance task, and it would be really great to be able to do it simply.

Incidentally, I recently had to undo a mistaken history merge, and it was a ridiculously complicated experience - see https://en.wikipedia.org/wiki/User:Scott/How_not_to_manage_article_history for the gory details - which would have benefited greatly from a RevisionMove tool.

(In reply to Scott Martin from comment #30)

Can this be normal priority rather than low?

It won't change much as long as nobody works on a patch...

(In reply to Nemo from comment #28)

In what does this differ from mergehistory?
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56356

Scott, we're still waiting for an answer to this question. If you want to see this bug move, the best you can do is to find or set up a test wiki (e.g. [[mw:MWV]]), enable mergehistory there, see what's missing from it, file bugs/enhancement requests.

That's a very reasonable request, Nemo, and I'll see if I can have a stab at it. Strikes me as a useful opportunity for a learning experience as well.

Tracked in Phabricator
Task T23312

Sometimes edit histories need to be cleaned up, particularly where it is discovered that an article has a lot of edits from an old improperly done cut-and-paste page move, or where an article is deleted, an article on a different topic happens to be written at the same title, and then the deleted article returns under a different title, with content that resolves whatever cause the initial deletion. Whatever the reason, there are sometimes circumstances where a block of edits in the current or deleted history of an article needs to be moved to a different title.

Currently, the way this is usually done is to:

1. delete the existing article, then
2. undelete the portion of the edit history to be moved, then
3. move the page generated by that undeletion to whatever the correct title is, without leaving a redirect then
4. undelete the edit history to be kept with the original title, and possibly
5. undelete any new edit history overwritten by the move of the old edits.

Occasionally all of this is complicated by the existence of deleted edits that need to stay deleted (such as periods when a copyvio was on the page). I can't put my finger on specific examples right now, but I would bet that User:Anthony Appleyard (who frequently cleans up such matters) can. What I would like it to able to just:

1. check off a block of edits in the edit history of an article (whether existing or deleted), and
2. move that block to the edit history of another article (without needing to delete/undelete anything).

If I am asked to history-merge page X (source) to page Y (destination), problems that arise are:-

1. Edits made to X after the cut-and-paste event: redirects, BattyBot and other bot edits, edits by someone starting a new article on the subject X or on another subject also describable as X.
2. Edits made to Y before the cut-and-paste event, often including redirects.
3. Miscellaneous old or new pre-existing deleted edits listed at page name X or Y.

I created this mockup: https://upload.wikimedia.org/wikipedia/mediawiki/d/d2/Screenshot-localhost-2019-02-26-23-07-41.png

Is a drop-down menu like that close to what you have in mind? (The "archive" function pertains to T213617; not sure if we'll actually be implementing that in the core)

If there was a "selective revision move" feature ...

But selective delete of edits would also be useful, in my experience.

In T23312#4990316, @Anthony_Appleyard wrote:

If there was a "selective revision move" feature ...

But selective delete of edits would also be useful, in my experience.

In this thread, they were talking about removing some of the deletion/undeletion functions we already have, rather than adding more. E.g., there would be no more selective restoration of revisions from the archive table; it would be all or nothing.

So what's the user interface for this going to look like? I'm thinking it's going to be like a cross between action=revisiondelete and Special:MovePage, because it'll list the revisions being moved and then ask where they're being moved to.

Or maybe it's going to look just like Special:MergeHistory, except with checkboxes instead of radio buttons.

Is there going to be a limit of 500 or 5000 revisions being moved at a time?

In my experience, if I do not have selective delete of edits, I would certainly need selective undelete of edits like we have now.

(Selective or non-selective move (while keeping them deleted) of the deleted edits which are listed under a page-name, would also be useful. If I have to work on an article, old deleted edits at the same page-name can get in the way of work.)

For example, in history-merging when page X had been cut-and-pasted to page Y, I often have first to clear away edits made to Y before the cut-and-paste event, and edits made to X after the cut-and-paste event, and other miscellanea.

In T23312#4990340, @Anthony_Appleyard wrote:

In my experience, if I do not have selective delete of edits, I would certainly need selective undelete of edits like we have now.

(Selective or non-selective move (while keeping them deleted) of the deleted edits which are listed under a page-name, would also be useful.)

So it sounds like there would be three special pages needed:

• Special:MoveRevisions (moves revisions from one page to another)
• Special:MoveDeletedRevisions (changes the page title of revisions that are in the archive table)
• Special:DeleteRevisions (moves selected revisions to the archive table)

(Not sure what names are ideal for these special pages; unfortunately, "archive" could refer to both a table that stores revisions of deleted pages, and a subpage where old content is moved; and "deleted revision" could refer to either a revision that's in the archive table because its page was deleted, or a revision whose visibility has been changed.)

The paid developers are mostly busy working on stuff like this, so a lot of features the users are interested in seeing implemented have to be coded by volunteers (aka people like you and me).

I'm going to be focused on Special:MoveRevisions, but if you want to code Special:MoveDeletedRevisions and Special:DeleteRevisions, I'm willing to help you to the extent I'm able, given my level of knowledge. It might not be that difficult of a project, since a lot of the code can probably be ripped off from, e.g., SpecialMovepage.php and/or HistoryAction.php and/or SpecialMergeHistory.php and/or SpecialUndelete.php.

We know there's a way to do this, and that we have all the documentation and code examples we would need, so you can't really fail, unless you reject the challenge or give up partway through. If you succeed, though, then maybe it'll impress the others enough to give you one of these barnstars.

... and "deleted revision" could refer to either a revision that's in the archive table because ...

It looks like that we have an ambiguity here. The sort of making edits visible or not visible, which is switched on and off by selecting in the column of square boxes in the edit-history display, and then clicking the long controls labeled "Change visibility of selected revisions" and "Edit tags of selected revisions" :: I tend to think of it as "hiding" or "unhiding"; and I think of the ordinary deleting (e.g. by clicking on the "delete" tab at the top of the page display) as "deleting".

And archiving by cutting-&-pasting a text section between e.g. Talk:Qwerty and Talk:Qwerty/Archive_34 , is something else again.

So where should the log entries get saved? Is this going to the move/revision log, kinda like how currently, revisiondelete actions go to the delete/revision log?

Here's a mockup I created. https://upload.wikimedia.org/wikipedia/mediawiki/2/27/Screenshot-localhost-2019.02.28-22-39-30.png

By the way, here's a link to churchofemacs's attempt from 2010: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/67094

See https://en.wikipedia.org/wiki/Talk:Black_sheep/Archive_1#Moves,_merges,_history for a complicated job that I had on 11 October 2007 tidying up pages about "Black Sheep".