Merge lp:~dernils/duplicity/documentation into lp:~duplicity-team/duplicity/0.8-series

[nils]

Minor changes to README-REPO, README-TESTING
Also re-done the changes to requirements.txt and Dockerfile

=== modified file 'Dockerfile'
--- Dockerfile	2017-04-23 10:06:47 +0000
+++ Dockerfile	2017-04-23 15:07:34 +0000
@@ -47,8 +47,8 @@
 RUN pip install --upgrade pip
 
 # Branch the dupllicity repo for testing 
-RUN bzr branch lp:~dernils/duplicity/testing
+RUN bzr branch lp:duplicity
 
 # Installing requirements for pip 
-RUN pip install -r ./testing/requirements.txt
+RUN pip install -r ./duplicity/requirements.txt
 

=== modified file 'README-REPO'
--- README-REPO	2017-04-22 19:30:28 +0000
+++ README-REPO	2017-04-23 15:07:34 +0000
@@ -26,39 +26,3 @@
 or
 
 PYTHONPATH=$DUP_ROOT bin/rdiffdir
-
------------------------
-Running the unit tests:
------------------------
-
-To run all tests:
-cd testing; ./run-tests
-
-You can run specific tests using:
-tox -- -s [folder].[folder].[file].[class].[test]
-For example:
-tox -- -s testing.unit.test_selection
-or:
-tox -- -s testing.unit.test_selection.MatchingTest.test_tuple_include
-
-Note: some tests require rdiff and pylint to be installed on the system for
-them to pass.
-
-Please run all tests on your branch (run-tests) before proposing a merge, to
-ensure that all tests pass. The decorator @unittest.expectedFailure can be used
-to commit a known-failing test case without breaking the test suite, for
-example to exhibit the behaviour in a bug report before it has been fixed.
-
------------------------------------------
-Testing against multiple Python versions:
------------------------------------------
-
-Duplicity uses tox to make it easy to test your code against multiple
-environments. Running tests using the commands above will automatically test
-code against different supported environments, including the versions of
-dependencies used by the Launchpad build system.
-
-You can test against a single environment, e.g.
-tox -e py27
-for example if you are working on fixing a bug, but please do a full run-tests
-before submitting a merge request.

=== modified file 'README-TESTING'
--- README-TESTING	2017-04-23 10:06:47 +0000
+++ README-TESTING	2017-04-23 15:07:34 +0000
@@ -30,17 +30,42 @@
 
 ‘setup.py test‘ 
 
-
 2. Using __tox__
 Tox is a generic virtualenv management and test command line tool that is used for checking your package installs correctly with different Python versions and interpreters. It 
 runs the tests in each of the environments that are configured in the tox.ini file (see root folder of the repository)
 
+Duplicity uses tox to make it easy to test your code against multiple
+environments. Running tests using the commands above will automatically test
+code against different supported environments, including the versions of
+dependencies used by the Launchpad build system.
+
+
 A tox run can be started simply by typing 
 
 ‘tox‘
 
 from the main duplicity folder. 
 
+You can run specific tests using:
+‘tox -- -s [folder].[folder].[file].[class].[test]‘
+For example:
+‘tox -- -s testing.unit.test_selection‘
+or:
+‘tox -- -s testing.unit.test_selection.MatchingTest.test_tuple_include‘
+
+You can test against a single environment, e.g.
+‘tox -e py27‘
+for example if you are working on fixing a bug, but please do a full run-tests
+before submitting a merge request.
+
+Note: some tests require rdiff and pylint to be installed on the system for
+them to pass.
+
+Please run all tests on your branch (run-tests) before proposing a merge, to
+ensure that all tests pass. The decorator @unittest.expectedFailure can be used
+to commit a known-failing test case without breaking the test suite, for
+example to exhibit the behaviour in a bug report before it has been fixed.
+
 3. Via a __docker__ image 
 Testing on a developer's machine can be tricky. Testing duplicity requires a set of dependencies being installed and reacts sensitiviely to changes of the local python configuration. In order to make sure that such interactions do not pose any influence on executing the tests, docker is the technology of choice. 
 Along with the tests, a docker image has been created (cf. Dockerfile in root folder of repo) that ensure the following things:

=== modified file 'requirements.txt'
--- requirements.txt	2017-04-22 19:30:28 +0000
+++ requirements.txt	2017-04-23 15:07:34 +0000
@@ -1,4 +1,11 @@
-dropbox
+dropbox==6.9.0
 lockfile
 pexpect
 pyrax
+pycryptopp
+paramiko
+urllib3
+boto
+tox
+coverage
+pylint 
\ No newline at end of file