Comment 9 for bug 374735

On Wed, 2009-08-12 at 05:58 +0000, Ian Clatworthy wrote:
> As long as stacking requires formats to be kept in sync across the base
> and stacked branch, upgrades will be semi-ugly.
>
> Is it really as simple as 'bzr upgrade URL' for a project trunk that has
> other branches stacked on it? Will those other branches continue to
> work? If not, then they must be upgraded as well, right? Until they are,
> won't they be broken?

They will be broken while the branch is upgraded.

> If so, then how does one find out what those impacted branches are? LP
> will need a feature to tell me those branches and who owns them. Owners
> are potentially anyone on LP, yes? IIUIC, the documented process solves
> this by simply leaving existing branches alone. So teams can upgrade
> trunk and just what they want to, when they want to. Isn't that better
> than putting teams into a situation where things they can't control will
> become broken?

folk with existing branches will have to update them anyway; and if
users on lp pivot the branch names around (so that they end up with
'trunk' again) the breakage of downstream branches will happen *anyway*.

> I appreciate that there are concerns re linked bugs by introducing a
> fresh trunk. OTOH, listing hundreds of bugs linked to trunk as LP does
> now is, well, questionable at best from a UI perspective. If this proves
> a real problem, then LP could gain a feature for moving linked bugs from
> one branch to another, say.

There is a bug on LP for an upgrade UI for branches anyway - it makes a
lot of sense for upgrading a project to 2a to be a button push in the
launchpad UI.

The problems as I see with the current documented process are that:
 - old branches won't get upgraded and will thus stay around forever, in
an incompatible format
 - bugs / merges / translations will still keep refering to old format
branches
 - the upgrade will cause a significant jump in disk usage (because the
old format trunk is left around).

AIUI there are some operational concerns about disk capacity on
launchpad anyway - having usage jump by 30% when everyone upgrades would
be a significant problem. Upgrading in place won't do that, because the
old branch data will be replaced (as further operations take place,
assuming they use your clean-up-aftwards flag). Even if they don't use
said flag, we could remove backup.bzr automatically (after health
checking the branch or something).

-Rob