Revert r35848 per Brion's WONTFIX of bug 14536: "This would just mean that there...
authorAryeh Gregor <simetrical@users.mediawiki.org>
Wed, 4 Jun 2008 23:45:01 +0000 (23:45 +0000)
committerAryeh Gregor <simetrical@users.mediawiki.org>
Wed, 4 Jun 2008 23:45:01 +0000 (23:45 +0000)
commit3857496fe2bda374229d0652a9cf51817cab165b
tree358fcf185028e18cc8c8fdf27967653cac3dc6e1
parent966352ed2fa517bb0698030c509edb887c1d8cbe
Revert r35848 per Brion's WONTFIX of bug 14536: "This would just mean that there's no practical way to move pages with their subpages."

Rate limits should be applied per user action, *not* based on how large the effect of each action is.  Note that moving a page with its talk page only counts as one move for rate limits; this is the same principle.  The only point of rate limits (as far as I can think of) is to prevent unauthorized automated scripts from creating a mess in 30 seconds that it will take 10 hours to clean up by hand.  Since a move with subpages is no harder to clean up (i.e., revert) than a move without subpages, they should count the same for rate limits.

Granted that at present, move with subpages *is* a little harder to revert: it requires a few more clicks, to go to the base target page and move back with subpages, as opposed to hitting a convenient revert link.  But it's not 100 times as hard to clean up, and doesn't remotely deserve to be treated as such.  (Unless you also want to delete the redirects, okay.  I grant that reverting moves with subpages could use improvement, but killing the feature entirely for non-sysops seems unreasonable at the present time.)
includes/SpecialMovepage.php