[RFC] upgrade ordering & UI

[Ian Clatworthy]

Hi all,

I've made good progress today on a better upgrade command. If you want
to test progress so far, grab a copy of lp:~bzr/bzr/smooth-upgrades. Of
course, this is *not* production code yet so try it on *copies* on your
data if you want to test it.

In particular, if you now pass upgrade the URL of a shared repo, it should:

1. upgrade the shared repo
2. upgrade dependent stacked branches
3. upgrade dependent unstacked branches

I'm planning to extend that with:

4. upgrade (lightweight) checkouts under the repo referencing those
   branches

Does that order sound right and should it always work? It seems to be
working for 1.6 => 1.9 upgrading but it seems to fail for
1.6 => development6-rich-root upgrading. In the latter case, I'm getting
an error (about an incompatible rich-root issue upgrading the stacked
branch from memory). Is that an ordering issue or a separate bug do you
think?

On the UI front, I have some things I'd like feedback on:

1. I'm planning to add a --clean option that will delete backup.bzr
   for things that successfully upgraded. I think explicit is good here.
   Does everyone agree? Right now, I do all the clean-up after all the
   upgrades. Would progressive clean-up be better? I guess it is if
   you interrupt things but it feels slightly less safe?

2. Robert has asked for an upgrade to dev6rr to be followed by a pack.
   Should that be implicit or an option? It seems to me that we ought to
   clean out obsolete_packs iff we pack as part of upgrade and --clean
   is given as an option. All agree?

3. I've suggested a --find option to search for repos/branches/checkouts
   to upgrade. I think that will be good because it allows upgrade to
   smartly order things, e.g. stacked before unstacked. Another option
   though is for upgrade to take a list of directories to upgrade. That
   seems more flexible but it then requires a separate command to find
   those directories and optionally intelligently order them. Any
   preference on direction here? (It will be a follow-up patch
   regardless.)

Ian C.