Ironing out the upgrade experience

[Martin Albisetti]

Hi,

I've had this in my head for ages, so I thought I'd put it out there
so it has a chance of actually being addressed  :)

As we approach 2.0 and upgrading formats becomes a key task we want
our users to perform, ironing out the experience becomes essential.
There are a few key issues with upgrade that I can think of that need
addressing, and I'm sure that there's a few that I've missed.

- Upgrading the same branch/repo multiple times gets you into trouble
if you leave the "backup.bzr" dir around. In cases like Launchpad,
this is very problematic because you need to start sftp'ing in and
doing all kinds of crazy thinks. Maybe we should create
"backup.bzr.1", "backup.bzr.2", etc?
- Upgrading via smart server. Right now, upgrading is crazy for large
branches because of all the data that needs to be transfered
- Upgrade sometimes downgrades. This should be stopped. I understand
why it's there, but we should provide a different mechanism, command
or switch for people who want to downgrade
- Document and push for a good story to upgrade stacked branches.
People struggle with this a lot, especially on Launchpad
- Give users more information on what to do when they run into
incompatible formats (ie, tell them how to upgrade, and to which
format). This will become more important as people start to move
project branches to the new format, and unaware users try to push/pull
their local branches
- Provide a way to "upgrade all the branches in this dir". Jelmer has
a recursive-upgrade plugin that I've hacked to pieces to use at the
office, but this functionality should really be in core

I'm pretty sure there's bugs filed for most of these issues. Maybe we
could put together a wiki page to follow up on this particular story?

-- 
Martin