> We'd need to a be a little careful, since in non-Launchpad cases,
> stacking a remote branch on some arbitrary URL is probably always the
> wrong thing to do, since there is no guarantee the other branch is
> sufficiently public *or* sufficiently persistent to serve as a stacking
> base.

Actually, even in the Launchpad case there's no guarantee that branches
are sufficiently persistent either.  e.g. if I make a feature branch
based off Alice's feature branch, and Alice deletes that branch when
it's merged.  I think that's probably a common enough scenario to be a
concern.

(Although Launchpad does somewhat encourage just leaving old branches
around because they are hidden by default and so there's not much cost
to keeping them.  But if nothing else it means the namespace is slowly
being consumed, so I'm sure some users will prefer to prune them.)

In theory in this case (Alice deleting the parent that we have stacked
on) Launchpad could make sure the stacked branch still works, by either:

 * noticing that another branch, e.g. the dev focus, now has all the
   required data and adjusting the stacking pointer accordingly.
   (Because if the branch is deleted it's fairly likely because it has
   been merged.)
 * unstacking the stacked branch (i.e. copying the required data and
   then removing the stacking pointer) before completing the deletion of
   the stacked-on branch.

Both are feasible but non-trivial.  In the general case we need to do
the second one as a fallback for the cases where there is no suitable
alternative stacking target.

A big advantage of using the dev focus as the default stacking location
in Launchpad is that the dev focus branch highly unlikely to be removed,
which has allowed us to avoid these questions.

> Other issues: we will have to consider is how much time we can
> reasonably take to probe branches for suitability as a stacking base
> before we make a decision and start actually transferring data. We will
> have to figure out whether any level of opt-in is required for branches
> to be considered as stacking bases, and if so who has permissions to do
> so.

In principle it should be fairly quick to determine if there's any
common history in the branch we want to push and the candidate stacking
location.  A crude but effective way would be to see if our revision 1
is present in the remote repo (and the cost of walking the full mainline
history locally, and perhaps adding 1 extra network roundtrip --
assuming the candidate location isn't stacked).

I think on balance having bzr consider :parent *if* the default location
has no common history *and* :parent is also on Launchpad is probably a
better tradeoff than surprisingly large and slow pushes, but I am
worried that it'll cause trouble down the track if parent branches are
later deleted.  (Thankfully I think Launchpad now gracefully copes with
stacked-on branches being renamed, which was the other big issue in the
past.)

A simple mitigation bzr could do pretty cheaply (and maybe in time for
2.4) would be:

 * fix 'bzr push --stacked-on=:parent' to work with lp: parents, and
 * if bzr notices there's no common history with the default stacking
   location, don't stack, and emit a warning saying “Not using default
   stacking location: no common history.  Perhaps try
   --stacked-on=:parent.”