2.0 upgrade experiences

[Eric Siegerman]

On Thu, 2009-08-13 at 17:58 +1000, Robert Collins wrote:
> On Thu, 2009-08-13 at 15:51 +0800, Martin Pool wrote:
> 
> > On upgrade we've normally already made a backup of the whole
> > repository so I think having it pass down a flag saying pack should
> > immediately remove obsolete data would be very safe.

Gee, I was just going to suggest that :-)

> In terms of recovery yes, unless the user uses the 'delete my backup
> afterwards' option.

Which is why users should be advised to keep backup.bzr around
for a while in case of problems.  (This is in addition to the
manual backup they're already advised to make before upgrading.)

A highly visible, clearly labelled backup makes perfect sense to
people; indeed, it should *add* to the user's warm fuzzy feeling
about the upgrade process, and by extension about bzr in general.

The problem is with a backup that lives three levels down in
what's supposed to be an opaque data structure (i.e. .bzr).  That
takes much more explanation, and leads to the "wtf?" perception
problems at issue here.  When obsolete packs are the only backup
there is, IMO that's a price clearly worth paying, but when
they're redundant (as I argue below), it isn't.

> I think that when we deliberately allow a race
> condition, particularly one that is hard to explain for all our users
to
> follow, we should seek a very strong cause for opening it.

In general, very true.  In this case, though, ISTM that it's an
essentially zero-risk race, as the data that risks being
corrupted has already been backed up in backup.bzr.

Indeed, in the specific case of a post-upgrade autopack (as
opposed to a post-commit autopack or explicit "bzr pack"),
wouldn't the obsolete packs be better understood as a temporary,
redundant intermediate stage between backup.bzr and the single
new über-pack, and thus completely disposable without a second
thought?

  - Eric