lp:~3v1n0/duplicity/copy.com-backend

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:~duplicity-team/duplicity/0.7-series at revision 990

duplicity-team: Pending requested 2014-06-16

Diff: 414 lines (+339/-1)

7 files modified

README (+1/-0)
bin/duplicity.1 (+7/-0)
duplicity/backend.py (+2/-1)
duplicity/backends/copycombackend.py (+319/-0)
duplicity/commandline.py (+1/-0)
testing/manual/backendtest (+6/-0)
testing/manual/config.py.tmpl (+3/-0)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #1315686: Please add Copy.com backend

Medium

Fix Released

Link a bug report

Related blueprints

997. By Marco Trevisan (Treviño) on 2014-06-16

README: add copy.com requirements

996. By Marco Trevisan (Treviño) on 2014-06-16

Add copy.com to man file

995. By Marco Trevisan (Treviño) on 2014-06-16

CopyComBackend: import non-main modules only when needed

994. By Marco Trevisan (Treviño) on 2014-06-16

CopyComBackend: remove unneded upload checks

993. By Marco Trevisan (Treviño) on 2014-06-16

CopyComBackend: implement _query method

Now the backend should be pretty complete

992. By Marco Trevisan (Treviño) on 2014-06-16

CopyComBackend: disable the _delete_list support, it won't work if a file doesn't exist

If a file in list does not exist, the Copy server will stop deleting the subsequent stuff,
raising an error and making test_delete_list to fail.

991. By Marco Trevisan (Treviño) on 2014-06-16

CopyComBackend: add ability to delete list of files

990. By Marco Trevisan (Treviño) on 2014-06-16

Backends: Add Copy.com support, implement basic operations

989. By Kenneth Loafman on 2014-05-11

* Update shebang line to python2 instead of python to avoid confusion.

988. By Kenneth Loafman on 2014-05-11

* Merged in lp:~mterry/duplicity/py2.6.0
  - Support python 2.6.0.
  - Without this branch, we only support python >= 2.6.5 because that's when
    python's urlparse.py module became its more modern incarnation. (I won't
    get into the wisdom of them making such a change in the middle of the
    2.6 lifecycle.)
  - Also, the version of lockfile that I have (0.8) doesn't work with python
    2.6.0 or 2.6.1 due to their implementation of
    threading.current_thread().ident returning None unexpectedly. So this
    branch tells lockfile not to worry about adding the current thread's
    identifier to the lock filename (we don't need a separate lock per thread,
    since our locking is per process).
  - I've tested with 2.6.0 and 2.7.6 (both extremes of our current support).