bzr-upload fails on first use when site already exists at remote server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Breezy |
Triaged
|
Medium
|
Unassigned | ||
bzr Upload plugin |
Confirmed
|
High
|
Unassigned |
Bug Description
It seems that if the site's directories and files already exist on the remote server, bzr-upload fails with an unhandled error.
$ bzr -Derror upload --remember ftp://ftp.
FTP <email address hidden> password:
No uploaded revision id found, switching to full upload
bzr: ERROR: bzrlib.
Traceback (most recent call last):
File "commands.py", line 846, in run_bzr_
File "commands.py", line 802, in run_bzr
File "commands.py", line 504, in run_argv_aliases
File "/home/
self.
File "/home/
self.
File "/home/
self.
File "/home/
self.
File "/home/
self.
File "ftp.py", line 353, in mkdir
File "ftp.py", line 193, in _translate_
FileExists: File exists: '/Foo': 550 /Foo: Access is denied.
bzr 1.4 on python 2.5.1 (cygwin)
arguments: ['/usr/bin/bzr', '-Derror', 'upload', '--remember', 'ftp://ftp.
encoding: 'US-ASCII', fsenc: 'US-ASCII', lang: None
plugins:
launchpad /usr/lib/
upload /home/johncc/
Changed in bzr-upload: | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: upload |
I think the error handling has changed a bit since 2008, but the problem continues more or less the same. Uploading a working tree to an sftp location fails if that location already exists. For example:
I first created a "testfolder" folder on my server. Then:
bzr upload -v sftp://<email address hidden>/testfolder
<email address hidden>'s password:
No uploaded revision id found, switching to full upload
bzr: ERROR: File already exists
If I then issue: /anothertestfol der
bzr upload -v sftp://<email address hidden>
(where anothertestfolder doesn't exists before running the bzr command)
then everything works as expected.
I think the problem comes from a call to transport. ensure_ base() from the upload plugin's upload_full_tree() function (line 227). Looks like ensure_base() returns errors that should be handled somehow, I'll see if I can work out a patch...