bzr could definitely benefit from using the parent branch as a stacking hint, where launchpad is concerned

We (bzr) could definitely do a lot better in the special case of Launchpad with some heuristics that included considering the branch parent as a stacking location, to accomodate the use-case of a long-term branch of a project (e.g. ubuntufication of d-i) which wants to use Launchpad's code review features (and so lots of feature branches are being pushed, which routinely contain revisions which will never enter the dev focus branch).

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.

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.

AFAIUI, on the launchpad side, stacked_on_location (which maxb forced) is controlled by the default_stacked_on config option.

I don't think this can be overriden (yet) in locations.conf (to be controlled locally for a branch or several).

In the end, I think the server (lp or not) should have a way to disallow stacking bases for safety (the case here *is* valid and safe).

FYI lp generates the default config file at runtime as a way of
controlling bzr's client side behaviour.

> 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'...