Race in puller with stacked branches

[Jonathan Lange]

If the puller mirrors a stacked branch before it mirrors the stacked-on branch, the mirrored branch is not going to work. It's not *so* bad, because the next time the puller runs, it *will* have the stacked-on branch and will thus be able to mirror the stacked branch.

[Jonathan Lange (jml)]

The problem is that we can try to mirror stacked branches before stacked-on branches are mirrored. The extreme form of this is when the stacked-on branch hasn't been mirrored at all. This leads to "Not a branch" errors on the stacked branch user page, and means that the stacked branch will not be available until a mirror is triggered on the stacked-on branch *followed by* a mirror being triggered on the stacked branch. That is, the stacked branch won't be available to the public until a long, long time after it's uploaded. Milder forms are when it's just out of date. This just leads to a bigger-than-necessary stacked branch.

I had a chat with Michael and we came up with this plan:

When mirroring a stacked branch:
    * check if the stacked-on branch is up-to-date (especially, does it exist?)
    * if it is, mirror as usual
    * if not, DEFER mirroring.

After *successfully* mirroring a stacked-on branch:
    * Request mirrors for all DEFERRED branches stacked on it.

The DEFER operation should look to the user as if no mirror attempt has been made, and make no promise about the next mirror time. We should be able to tell when a branch is DEFERRED because last_mirror_attempt > last_mirrored. (This is ugly. We should change the schema so we can be explicit about this. Options include: explicit status field; recording the rev id of the tip of the branch in the upload area; changing the schema to be more like code imports).

[Jonathan Lange (jml)]

This is in PQM now.

[Jonathan Lange (jml)]

RF 6997