Node Revision Cleanup

There are a couple really good modules out there for periodic revision maintenance and keeping node revisions in check, namely Node Revision Delete and Node Revision Restrict. These modules aim to make regular maintenance of your revisions easier to prevent revisions tables from growing too large. Stop here and try one of those projects if you have fewer than half a million rows in node_revision. Otherwise, continue on, brave soldier.

Node Revision Cleanup is designed for really big databases. And site administrators who are comfortable with Drush. The concept behind this module is to be able to run multiple invocations at the same time, via Drush to maximize the number of node revision deletions per second. On my development machine, for example, I can run one invocation of nrc and achieve about 30 node revision deletions per second. Or, I can run four, and hit 120 node revision deletions per second. Imagine what a difference that makes when you're staring down a database with 2 million + rows in node_revision? The difference is being able to clean that bad boy up in an afternoon (little over 4.5 hours) versus. Oh, hey! I almost forgot to ask. Have a spare terminal tab to spare? Heh. Sure you do. There's also a progress reporter option that you can run with watch to keep up with the action!

Instructions
Read the manual...er...Read the README. It's chock full of information and witty humor.

But, I'm sure you just want the quick version, so, here:

1. Back up your database. This process is pretty safe, but I'm not taking responsibility if something goes wrong.
2. Run
   drush nrc-gq %content-type% --revisions=%revisions-to-keep%
   OR
   drush nrc-gq %content-type% --tp=%time-phrase%

   where %content-type% is the machine name of the content type for which you wish to delete revisions.

   In the first case, provide the option --revisions with %revisions-to-keep%, which is the number of revisions you wish to maintain per node of that content type. Revisions are removed, oldest first.

   In the second case, pass the --tp option with %time-phrase% being a string that PHP's date_modify() can understand like "-30 days" or "-1 year". All of the node revisions younger than the specified %time-phrase% will be kept. The %time-phrase% is relative to the time the script is initiated.

   Yes, you can pass a future date. That will wipe out all but the most recent revision.

3. Run drush nrc-wl %content-type% %group-number% &, using the same %content-type% you entered to generate the work list. %group-number% should be a number to indicate which process group this is. Adding the ampersand at the end tells bash to return the shell to your command so you can run a second or third or nth instance of the script at the same time. The function returns a message after its finished working the available lists. When running more than one iteration, I do something like:
   

   $ echo '' > /path/to/report-file.txt
   $ drush nrc-wl blog 1 >> /path/to/report-file.txt &
   $ drush nrc-wl blog 2 >> /path/to/report-file.txt &
   $ drush nrc-wl blog 3 >> /path/to/report-file.txt &

   This collects the output of all instances of the script in the same file, rather than returning their output on the command line.
   Alternatively, run the following in screen or tmux sessions:

   $ drush nrc-wl blog 1
   $ drush nrc-wl blog 2
   $ drush nrc-wl blog 3

   I've recently stopped caring about the reporting function on individual runs and the process group option may go away in the future (along with the reporting) unless someone wishes to flesh out a better use in a patch submission.

4. View your progress by running drush nrc-report %content-type%, again, entering the content type for which you generated the job queue. If you have watch installed on the machine on which you're working, you can run watch -n2 drush nrc-report %content-type% and get the play-by-play.

Notes/Requests
Depending on the amount of cleanup you have to do, this process can take a very long time. I would love to hear from anyone who knows more about the command line and can give tips on how to tell the system to dedicate more resources to an instance of the script. I've had varying results, from as low as 3% CPU usage to 40% CPU usage dedicated to one instance of running this script on my development machine, under seemingly similar circumstances. Given that, any advice on this front would be greatly appreciated!

FWIW: This project was originally named "Unicorn Riding, Gigadeath Canon Wielding Node Revision Defeater of Awesomeness", I decided to tone the project title down just a bit, in case you didn't find this little gem as amazing as I did. And why wouldn't I? I wrote it!

Further development

If you read the Similar Projects section in the Node Revision Delete module you will see that at this moment there are 10 modules that works with the Cleanup of Revisions:

• Node Revision Bulk Delete
• Node Revision Cleanup
• Revisionator
• Node Revision Restrict
• Revision Deletion
• Node revisions autoclean
• Revision disintegrate
• Revision Purger
• Revision Snip
• Node Revision Delete

We don't need all these modules to clean revisions when we can have only one, is more easy to maintain and we can concentrate efforts, the only module that is being migrated to Drupal 8 is #2866825: [node_revision_delete] Node Revision Delete and at the same time the new features are backported to the 7.x-3.x version. So, we recommend you to use the Node Revision Delete module.