© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
@Petr
Excellent !
Thanks a ton, highlighting use cases is the best thing to do to help us enhance bzr-upload.
You rightly point out that bzr-upload should be more robust against *transient* failures, because its' needed for both incremental and full upload.
This is a known problem and mostly concern the ftp protocol (see bug #127164).
For truly lost connections (like network cable unplugged say), we need a journaled upload which is orders of magnitude more complex, so don't hold your breadth on that one (but patches welcome :).
Regarding your use case (symlinks), you're right about bug #214825, but that's only a symptom of a deeper problem: the plugin expects that the revid it uploaded (in the .bzr-upload.revid file on the remote site) guarantees that the uploaded tree is *exactly* the revision tree it can refer to locally. Any difference introduced for one reason or another is a source of problems (any modification involving a file *not* uploaded can't be handled anymore).