[MERGE] --no-backup option for bzr upgrade (#118653)

[Marius Kruger]

Another option is to just change the --no-backup behavior
to automatically delete the backup once everything was successful,
in stead of not backing up at all.

(this could even become the default, as this .bzr.backup directories lying
around are a bit of a annoyance)

On 7/20/07, Robert Collins <robertc at robertcollins.net> wrote:
>
> On Tue, 2007-07-10 at 17:19 +0200, Lukáš Lalinský wrote:
> > On St, 2007-07-11 at 01:01 +1000, Robert Collins wrote:
> > > However --no-backup is really very dangerous; more dangerous than you
> > > might predict.
> > >
> > > Specifically any sort of link error will leave branches/repositories
> in
> > > an unrecoverable state if no backup has been taken.
> >
> > For this particular case, I don't think this is a big problem, because
> > you can simple re-upload the code to launchpad. But I understand that in
> > general is --no-backup a bad idea.
> >
> > > Further to that some
> > > upgrades will use the backup as the source for the upgraded data so we
> > > may not be able to avoid it per se without changing where we make the
> > > backup too...
> >
> > Hmm, it looks like some upgrade tests are missing because no backup
> > doesn't break any of them. :)
>
> Uhm, possibly I was wrong about current code using the backup. Looks
> like it takes another backup inside the dir; anyhow - that is something
> that obviously could be fixed.
>
> The problem with unrecoverability is *much* more important and harder to
> solve though.
>
> Theres no way to tell that a use actually has a local copy - its
> entirely possible for people to work solely with lightweight checkouts
> against launchpad, and in this case there is no local copy to re-upload
> in the event of failure.
>
> -Rob
> --
> GPG key available at: <http://www.robertcollins.net/keys.txt>.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20070725/c37c9f3c/attachment-0001.htm