merge Chris Rose changes and enhancements/fixes to issue10 and 15

3 files changed, 25 insertions, 24 deletions

diff --git a/doc/example/basic.txt b/doc/example/basic.txt
index 3ceeb87..9bf0b68 100644
--- a/doc/example/basic.txt
+++ b/doc/example/basic.txt
@@ -103,3 +103,4 @@ To for tox to recreate a (particular) virtual environment::
 
 would trigger a complete reinstallation of the existing py27 environment
 (or create it afresh if it doesn't exist).
+
diff --git a/doc/example/general.txt b/doc/example/general.txt
index f8c316e..2cee354 100644
--- a/doc/example/general.txt
+++ b/doc/example/general.txt
@@ -99,7 +99,7 @@ Access package artifacts between multiple tox-runs
 If you have multiple projects using tox you can make use of
 a ``distshare`` directory where ``tox`` will copy in sdist-packages so
 that another tox run can find the "latest" dependency.  This feature
-allows to to test a package against an unreleased development version
+allows to test a package against an unreleased development version
 or even an uncommitted version on your own machine.
 
 By default, ``{homedir}/.tox/distshare`` will be used for
@@ -120,7 +120,7 @@ into the ``distshare`` directory after which a ``tox`` run on project
 highest version will be taken.  ``tox`` uses verlib_  to compare version
 strings which must be compliant with :pep:`386`.
 
-If you want to use this with Hudson_, also checkout the :ref:`hudson artifact example`.
+If you want to use this with Jenkins_, also checkout the :ref:`jenkins artifact example`.
 
 .. _verlib: http://bitbucket.org/tarek/distutilsversion/
 
diff --git a/doc/example/hudson.txt b/doc/example/jenkins.txt
index d0a1691..ad26f60 100644
--- a/doc/example/hudson.txt
+++ b/doc/example/jenkins.txt
@@ -1,23 +1,23 @@
 
-Using Tox with the Hudson Integration Server
+Using Tox with the Jenkins Integration Server
 =================================================
 
-Using Hudson multi-configuration jobs
+Using Jenkins multi-configuration jobs
 -------------------------------------------
 
-The Hudson_ continous integration server allows to define "jobs" with
+The Jenkins_ continous integration server allows to define "jobs" with
 "build steps" which can be test invocations.  If you :doc:`install <../install>` ``tox`` on your
-default Python installation on each Hudson slave, you can easily create
-a Hudson multi-configuration job that will drive your tox runs from the CI-server side,
+default Python installation on each Jenkins slave, you can easily create
+a Jenkins multi-configuration job that will drive your tox runs from the CI-server side,
 using these steps:
 
 * create a "multi-configuration" job, give it a name of your choice
-* configure your repository so that Hudson can pull it
+* configure your repository so that Jenkins can pull it
 * (optional) configure multiple nodes so that tox-runs are performed
   on multiple hosts
 * configure ``axes`` by using :ref:`TOXENV <TOXENV>` as an axis
   name and as values provide space-separated test environment names
-  you want Hudson/tox to execute.
+  you want Jenkins/tox to execute.
 
 * add a **Python-build step** with this content (see also next example)::
 
@@ -25,7 +25,7 @@ using these steps:
     tox.cmdline() # environment is selected by ``TOXENV`` env variable
 
 * check ``Publish JUnit test result report`` and enter
-  ``**/junit-*.xml`` as the pattern so that Hudson collects
+  ``**/junit-*.xml`` as the pattern so that Jenkins collects
   test results in the JUnit XML format.
 
 The last point requires that your test command creates JunitXML files,
@@ -33,16 +33,16 @@ for example with ``py.test`` it is done like this:
 
     commands=py.test --junitxml=junit-{envname}.xml
 
-See a real-life example in action with the `pytest Hudson job`_
+See a real-life example in action with the `pytest Jenkins job`_
 
-.. _`pytest Hudson job`: http://hudson.testrun.org/view/pytest/job/pytest/
+.. _`pytest Jenkins job`: http://jenkins.testrun.org/view/pytest/job/pytest/
 
 **zero-installation** for slaves
 -------------------------------------------------------------
 
 .. versionadded:: 0.9
 
-If you manage many Hudson slaves and want to use the latest officially
+If you manage many Jenkins slaves and want to use the latest officially
 released tox (or latest development version) and want to skip manually
 installing ``tox`` then substitute the above **Python build step** code
 with this::
@@ -67,10 +67,10 @@ install ``tox`` in a virtual sub environment.  Notes:
 
 .. _`toxbootstrap.py`: https://pytox.googlecode.com/hg/toxbootstrap.py
 
-Integrating "sphinx" documentation checks in a Hudson job
+Integrating "sphinx" documentation checks in a Jenkins job
 ----------------------------------------------------------------
 
-If you are using a multi-configuration Hudson job which collects
+If you are using a multi-configuration Jenkins job which collects
 JUnit Test results you will run into problems using the previous
 method of running the sphinx-build command because it will not
 generate JUnit results.  To accomodate this issue one solution
@@ -106,27 +106,27 @@ Here is an example:
               "-d", str(doctrees), ".", str(htmldir)])
 
 3. run ``tox -e docs`` and then you may integrate this environment
-   along with your other environments into Hudson.
+   along with your other environments into Jenkins.
 
 Note that ``py.test`` is only installed into the docs environment
 and does not need to be in use or installed with any other environment.
 
-.. _`hudson artifact example`:
+.. _`jenkins artifact example`:
 
-Access package artifacts between Hudson jobs
+Access package artifacts between Jenkins jobs
 --------------------------------------------------------
 
-.. _`Hudson Copy Artifact plugin`: http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin
+.. _`Jenkins Copy Artifact plugin`: http://wiki.jenkins-ci.org/display/HUDSON/Copy+Artifact+Plugin
 
-In an extension to :ref:`artifacts` you can also configure Hudson jobs to
+In an extension to :ref:`artifacts` you can also configure Jenkins jobs to
 access each others artifacts.  ``tox`` uses the ``distshare`` directory
-to access artifacts and in a Hudson context (detected via existence
+to access artifacts and in a Jenkins context (detected via existence
 of the environment variable ``HUDSON_URL``); it defaults to
 to ``{toxworkdir}/distshare``.
 
 This means that each workspace will have its own ``distshare``
-directory and we need to configure Hudson to perform artifact copying.
-The recommend way to do this is to install the `Hudson Copy Artifact plugin`_
+directory and we need to configure Jenkins to perform artifact copying.
+The recommend way to do this is to install the `Jenkins Copy Artifact plugin`_
 and for each job which "receives" artifacts you add a **Copy artifacts from another project** build step using roughly this configuration::
 
     Project-name: name of the other (tox-managed) job you want the artifact from
@@ -145,7 +145,7 @@ Now everything proceeds as :ref:`artifacts` shows it.
 
 So if you are using defaults you can re-use and debug exactly the
 same ``tox.ini`` file and make use of automatical sharing of
-your artifacts between runs or Hudson jobs.
+your artifacts between runs or Jenkins jobs.
 
 .. include:: ../links.txt