Allow .bzr.backup on SFTP and smartserver

[Loïc Minier]

Hi,

I created a bzr repo with the default format, pushed it to launchpad, but was in the need for tags; bzr requested me to upgrade, which I did, but I couldn't push to launchpad anymore after the upgrade since the remote branch needed an upgrade too.

launchpad doesn't allow the backup copy .bzr.backup, and there was no command-line flag to disable it; I commented out the self._backup_control_dir() call in upgrade.py.

Please add a flag to disable .bzr.backup.

Bye,

[Szilveszter Farkas (phanatic)]

I'm not sure if it helps, but have you tried 'bzr push --overwrite'?

[Loïc Minier (lool)]

I did, but like push it would complain that the remote branch needed an upgrade.

[John A Meinel (jameinel)]

push --overwrite just forces the revision contents, it doesn't change the format.
I've used "bzr upgrade sftp://bazaar.launchpad.net/...." before

It sounds like the problem is that this was attempted one time, and now there is a .bzr.backup directory lying around that is preventing it from being done again.

With an sftp client you could "sftp sftp://bazaar.launchpad.net/; cd path; mv .bzr.backup .bzr.backup.old"

And then upgrade should work.

Alternatively 'bzr upgrade' could do some sort of .bzr.backup.N (.1, .2, .3... etc) chaining. But I'm not sure what the best answer is.

[Loïc Minier (lool)]

lool@bee ~ 8 255 % sftp bazaar.launchpad.net
2007/06/04 19:13:22
Connecting to bazaar.launchpad.net...
cd ~lool
sftp> cd ~lool
sftp> ls
+junk python-launchpad-code
sftp> cd python-launchpad-code
sftp> ls
trunk
sftp> ls -a
. .. trunk
sftp> cd trunk
sftp> ls
sftp> ls -a
. .. .bzr

I don't think I left any .bzr.backup, and the message sounded clear to me, but I don't have it for reference anymore.

[John A Meinel (jameinel)]

I think this is actually a bug in launchpad-bazaar, and I will include them on this. But the following commands should succeed, but currently fail:

% bzr init sftp://bazaar.launchpad.net/~jameinel/+junk/test1
$ bzr upgrade --dirstate-tags sftp://bazaar.launchpad.net/~jameinel/+junk/test1
starting upgrade of sftp://bazaar.launchpad.net/%7Ejameinel/%2Bjunk/test1/
making backup of tree history
bzr: ERROR: Permission denied: u'/~jameinel/+junk/test1/.bzr.backup': [Errno 13] Can only create .bzr directories in branch directories: .bzr.backup

[John A Meinel (jameinel)]

This seems like an explicit design decision (since we have an explicit "cannot create anything but .bzr" error message).

However, somebody didn't realize how we do upgrades. I would rather not have a "--no-backup" because then if the upgrade fails midway through (disconnected net access) you potentially have corrupted your branch completely, and have no easy way to fix it.

[Andrew Bennetts (spiv)]

John A Meinel wrote:
[..]
> It sounds like the problem is that this was attempted one time, and now
> there is a .bzr.backup directory lying around that is preventing it from
> being done again.

That's not the problem. The problem is that recently the SFTP server stopped
allowing creation of any directory other than ".bzr" at that point in the
filesystem hierarchy (to prevent mistakes where users pushed to a directory too
deep, and thus made a branch Launchpad couldn't mirror).

Unfortunately, that includes ".bzr.backup". So probably that restriction in
Launchpad needs to be loosened slightly.

Of course, .bzr.backup are pretty inconvenient in Launchpad anyway, because how
can you revert to the backup .bzr if there's a problem? You need to find an
SFTP client that can recursively delete directories, then move the old one back.
And unless you only use a given branch as a checkout, you've probably tested the
upgrade locally anyway. So I think adding a --no-backup flag to upgrade would
be handy anyway.

-Andrew.

[Jonathan Lange (jml)]

Yeah, we should probably loosen the restrictions on Launchpad.

[Jelmer Vernooij (jelmer)]

Perhaps the upgrade process is something that can later be deferred to the smart server.

[Robert Collins (lifeless)]

I think:
 - we should support .bzr.backup on the SFTP server as a priority. (note bzr+ssh already supports this AFAICT)
 - the smart server will support upgrades eventually
 - lftp does recursive rm's easily so its easy to recover
 --no-backup is a really bad idea. Lets not create a situation where users can trash their data irrecoverably due to e.g. network interruptions.

[Robert Collins (lifeless)]

--no-backup is a recipe for trashing data when link errors occur. I think its a harmful thing to include because users won't predict that it can do that.