Description:
With RevisionDelete in action, the only time that delete + partial undelete is needed is for complex history merges and fixing copy/paste moves.

It seems cumbersome that admins must repeatedly delete and part-undelete to selectively move revisions and repair cut/paste moves. If there was a "selective revision move" feature (RevisionMove?) that allowed administrators to select various revisions on a page and move them to another page somehow (in line with the needs of page merge and copypaste fixing), this would greatly simplify page merges and copypaste fixing. In fact there would be no obvious remaining need for selective revision deletion; it could all be done using RevisionDelete and RevisionMove, simplifying admin work considerably.

As a further thought, if RevisionMove were created, then partial delete/undelete could be withdrawn, and the link breakage bug 21279 would mostly cease to be an issue.

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.

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.

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.

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.

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.

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:

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.

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.

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:

Schema changes suck.

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

Users who have permissions to move revisions (I suggest admins by default) usually know what they're doing.

The current revision move process (delete, partial undelete, move, undelete) allows you to screw up just as bad

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 ;))

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".

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.

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 #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 #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.

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?

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.

Add Comment

Text is available under the Creative Commons Attribution-ShareAlike 3.0 License; code is available under the GNU General Public License or other appropriate open source licenses. By using this site, you agree to the Terms of Use and Privacy Policy. · Wikimedia Foundation · Privacy Policy · Terms of Use · Disclaimer

Column Prototype

This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.