diff --git a/committing.rst b/committing.rst
--- a/committing.rst
+++ b/committing.rst
@@ -424,95 +424,6 @@
 .. warning::
     Never use ``hg merge`` to port changes between 2.x and 3.x (or vice versa).
 
-Using several working copies
-''''''''''''''''''''''''''''
-
-If you often work on bug fixes, you may want to avoid switching branches
-in your local repository.  The reason is that rebuilding takes time
-when many files are updated.  Instead, it is desirable to use a separate
-working copy for each maintenance branch.
-
-There are various ways to achieve this, but here is a possible scenario:
-
-* First do a clone of the public repository, whose working copy will be
-  updated to the ``default`` branch::
-
-   $ hg clone ssh://hg@hg.python.org/cpython py3k
-
-* Then clone it to create another local repository which is then used to
-  checkout branch 3.3::
-
-   $ hg clone py3k py3.3
-   $ cd py3.3
-   $ hg update 3.3
-
-* Then clone it to create another local repository which is then used to
-  checkout branch 3.2::
-
-   $ hg clone py3.3 py3.2
-   $ cd py3.2
-   $ hg update 3.2
-
-* If you also need the 3.1 branch to work on security fixes, you can similarly
-  clone it, either from the ``py3.2`` or the ``py3k`` repository. It is
-  suggested, though, that you clone from ``py3.2`` as that it will force you
-  to push changes back up your clone chain so that you make sure to port
-  changes to all proper versions.
-
-* You can also clone a 2.7-dedicated repository from the ``py3k`` branch::
-
-   $ hg clone py3k py2.7
-   $ cd py2.7
-   $ hg update 2.7
-
-Given this arrangement of local repositories, pushing from the ``py3.2``
-repository will update the ``py3.3`` repository, where you can then merge your
-3.2 changes into the 3.3 branch.  In turn, pushing changes from the ``py3.3``
-repository will update the ``py3k`` repository.  Finally, once you have
-merged (and tested!) your ``3.3`` changes into the ``default`` branch, pushing
-from the ``py3k`` repository will publish your changes in the public
-repository.
-
-When working with this kind of arrangement, it can be useful to have a simple
-script that runs the necessary commands to update all branches with upstream
-changes::
-
-  cd ~/py3k
-  hg pull -u
-  cd ~/py3.3
-  hg pull -u
-  cd ~/py3.2
-  hg pull -u
-  cd ~/py2.7
-  hg pull -u
-
-Only the first of those updates will touch the network - the latter two will
-just transfer the changes locally between the relevant repositories.
-
-If you want, you can later :ref:`change the flow of changes <hg-paths>` implied
-by the cloning of repositories. For example, you may choose to add a separate
-``sandbox`` repository for experimental code (potentially published somewhere
-other than python.org) or an additional pristine repository that is
-never modified locally.
-
-
-Differences with ``svnmerge``
-'''''''''''''''''''''''''''''
-
-If you are coming from Subversion, you might be surprised by Mercurial
-:ref:`merges <hg-merge>`.
-Despite its name, ``svnmerge`` is different from ``hg merge``: while ``svnmerge``
-allows to cherry-pick individual revisions, ``hg merge`` can only merge whole
-lines of development in the repository's :abbr:`DAG (directed acyclic graph)`.
-Therefore, ``hg merge`` might force you to review outstanding changesets by
-someone else that haven't been merged yet.
-
-
-.. seealso::
-   `Merging work
-   <http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html>`_,
-   in `Mercurial: The Definitive Guide <http://hgbook.red-bean.com/>`_.
-
 
 Long-term development of features
 ---------------------------------