Merge lp:~mterry/duplicity/retry-decorator into lp:duplicity/0.6
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Kenneth Loafman | ||||
Approved revision: | 726 | ||||
Merged at revision: | 738 | ||||
Proposed branch: | lp:~mterry/duplicity/retry-decorator | ||||
Merge into: | lp:duplicity/0.6 | ||||
Prerequisite: | lp:~mterry/duplicity/gio-name | ||||
Diff against target: |
130 lines (+50/-29) 2 files modified
duplicity/backend.py (+18/-0) duplicity/backends/giobackend.py (+32/-29) |
||||
To merge this branch: | bzr merge lp:~mterry/duplicity/retry-decorator | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
duplicity-team | Pending | ||
Review via email: mp+63571@code.launchpad.net |
Description of the change
This branch adds a decorator to duplicity.backend for use by the backends if they like. Decorators were added in Python 2.4, so I believe it's safe to rely on.
I then started using the decorator in the giobackend. And finally (the real purpose of all this), I added the decorator to giobackend's list and delete operations.
This was motivated by bug 545486 where the user was getting the message "No data available" seemingly because there was a long gap between mounting the remote location and doing the first operation (list) due to scanning during a dry-run. The first list operation would fail, but if we did a second one, it would succeed.
Presumably GIO was reconnecting but still failing that first time. Seems like bad GIO design, but this works around it anyway. Plus, better to retry than not whenever we hit the backend. Some of the same issues with put/get can be had with list/delete.
I haven't converted any of the other backends to use the decorator, but it seems like it could reduce a bit of code.