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) <div>On 7/20/07, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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: <<a href="http://www.robertcollins.net/keys.txt">http://www.robertcollins.net/keys.txt</a>>. </blockquote></div>