Comment 8 for bug 215612

@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).