Extension:MirrorTools/Design decisions

Permanently stationary revisions vs. moving and being recalled revisions
Under the "permanently stationary" system, any revisions made on LocalWiki stay at that page ID, page title, and page namespace until they are moved, undeleted, etc. on Wikipedia. Under the "moving and being recalled" system, once a page is deleted on RemoteWiki, those revisions fall under LocalWiki control and can be moved about, but if the page is undeleted, the revisions are recalled to what their page ID, page title, and page namespace are on Wikipedia.
 * Argument
 * Decision: MirrorTools will use the "permanently stationary" system because of a principle that is analogous to "Cool URIs don't change".

Deleting revisions vs. not deleting revisions when pages are mirrormoved onto them
We shouldn't delete anything! On the other hand, redirects to the source page have no information we don't already have, when they're being moved onto.
 * Argument
 * Decision: It was decided that if the only remotely live revision is a redirect back to the page being moved onto it, to go ahead and delete that, but merge everything else.

Keep rev_parent_id vs. change rev_parent_id
Should those be set to their local or remote parent_ids? Probably the remote, and then the local ones should be left as they are. Reason being, we don't want to change the old and new lens. On the other hand, what happens when we add a new local edit? Then it would base the difference in page lengths off the imported revision length. Let's let the users sort this out.
 * Argument

Pros to "keep":
 * We don't have a bunch of wacky len changes
 * Performance, e.g. in mirrormoves we don't have to change all the parent_ids

Pros to "change":
 * Things could get theoretically get ugly with the page lengths, e.g. if we have revisions getting moved. But not really, because it will still base it off that revision, even if it's in a different page.

There will be a config setting, $wgMirrorToolsDynamicParentIDs, that defaults to false (i.e. static).
 * Decision

Add a null revision for deletion events
Before going that route, maybe we should try to find out why some log events have null revisions and others don't. See Manual:Null revision.

Assume vs. don't assume that MirrorPullBot has access to the backend
Don't assume. Operate as if it doesn't have access.