Last modified: 2013-04-19 10:20:51 UTC
When we perform actions that are logged in [[Special:Log]], a null revision is usually (not always, eg user rights changes) made in the history of the affected page with the same data as the log entry. These entries should obviously be considered interchangeable, so when a log entry is hidden, the corresponding null revision should have the same hiding settings applied to it, and vice versa. For pagemove results, hiding one entry should probably also affect the equivalent entries for the other page. Essentially, whenever multiple records are created together, they should be treated as one record for the purposes of RevisionDelete.
Not sure if there's an efficient way to do this. I don't think there's any correlation between the log entry and the null revisions made, except maybe the timestamp, but from a quick test, these aren't guaranteed to be exactly the same down to the second.
Well you can pick them up based on timestamp and confirm by comparing the summaries, or we could try to link them; maybe we could use rev_parent_id to link to the log entry, although I'm not 100% sure what that's used for, and there's no reciprocal arrangement (although we couldn't set reciprocal links without three database commits anyway). Remember that these are not arbitrary: if you're hiding a log entry, you *know* how many null revisions are associated with it - for a protect/unprotect/modifyprotect, there's one and for a move there's three - the corresponding move log entry for the other end of the move, and null revisions in both pages' histories. It shouldn't be too hard to locate these and track them down.
The problem is that the summary in the page history is dependent on a system message, which can be edited, so also can't be guaranteed to be consistent. And as I said, there's no guarantee that timestamps are going to be the same, if you have a protection-conflict on a page, you might have 1 null revision made at the same time a different protection log entry was created. You could compare the user to the log, but its still adding more convolutions. The fact that you know how many null revisions there are doesn't really help all that much. If there's only 1 it makes it easier, but it doesn't really help in establishing a relationship between a log entry and a revision. The only thing I can see that would distinguish a log-null-revision from a normal edit is that rev_len is null, though this is null (I think) for all revisions before it was implemented (sometime in the last couple years I think), so could potentially have issues with older wikis. Also, I'm quite sure if its supposed to be null now, or if that was just an omission when adding the column (null revision adding uses a different function than real revision adding). If its the latter, then its not a reliable option for future revisions either. The other, potentially big, problem, is that logs, since they can apply to deleted and non-existent pages, as well as special pages, use titles rather than pageids. So when a page is moved, the null revisions from the history are now associated with one title (revisions use pageid), while the logs will be associated with another. So when searching for the null revision, it would have to check if the page has been moved, then check if that page has been moved, etc. New pages can be created over the old title though, potentially causing more problems (and those can be moved and the title resused, etc, etc) It would also have to check the archive table for deleted revs, if it can't find it in the revision table. Doing it the other way around, searching from null revision to log entry would have the same problems.
This won't be possible in the foreseeable future. Several tracking schema changes would be need for log->revision, revision->log and logging tracking for log/delete,log/suppress. For now, we can just check the history links given at revisiondelete.
resetting assignee
