Fill in explanation of why hg was chosen.

pep-0374.txt

@@ -1473,5 +1473,82 @@ not only lists the delta change information for each file but also
 color-codes the information.
 
 
-XXX ... usage on top of svn, filling in `Coordinated Development of a
+Decision
-New Feature`_ scenario
+=========
+
+At PyCon 2009 the decision was made to go with Mercurial.
+
+
+Why Mercurial over Subversion
+-----------------------------
+
+While svn has served the development team well, it needs to be
+admitted that svn does not serve the needs of non-committers as well
+as a DVCS does. Because svn only provides its features such as version
+control, branching, etc. to people with commit privileges on the
+repository it can be a hinderance for people who lack commit
+privileges. But DVCSs have no such limitiation as anyone can create a
+local branch of Python and perform their own local commits without the
+burden that comes with cloning the entire svn repository. Allowing
+anyone to have the same workflow as the core developers was the key
+reason to switch from svn to hg.
+
+Orthogonal to the benefits of allowing anyone to easily commit locally
+to their own branches is offline, fast operations. Because hg stores
+all data locally there is no need to send requests to a server
+remotely and instead work off of the local disk. This improves
+response times tremendously. It also allows for offline usage for when
+one lacks an Internet connection. But this benefit is minor and
+considered simply a side-effect benefit instead of a driving factor
+for switching off of Subversion.
+
+
+Why Mercurial over other DVCSs
+------------------------------
+
+Git was not chosen for three key reasons (see the `PyCon 2009
+lightning talk <http://pycon.blip.tv/file/1947231/>`_ where Brett
+Cannon lists these exact reasons; talk started at 3:45). First, git's
+Windows support is the weakest out of the three DVCSs being considered
+which unacceptable as Python needs to support development on any
+platform it runs on. Since Python runs on Windows and some people do
+develop on the platform it needs solid support. And while git's
+support is improving, as of this moment it is the weakest by a large
+enough margin to warrant it a problem.
+
+Two, and just as important as the first issue, is that the Python
+core developers liked git the least out of the three DVCS options by a
+wide margin. If you look at the following table you will see the
+results of a survey taken of the core developers and how by a large
+margin git is the least favorite version control system.
+
+==== == ===== == ==========
+DVCS ++ equal -- Uninformed
+---- -- ----- -- ----------
+git  5  1     8  13
+bzr  10 3     2  12
+hg   15 1     1  10
+==== == ===== == ==========
+
+Lastly, all things being equal (which they are not
+as shown by the previous two issues), it is preferable to
+use and support a tool written in Python and not one written in C and
+shell. We are pragmatic enough to not choose a tool simply because it
+is written in Python, but we do see the usefulness in promoting tools
+that do use it when it is reasonable to do so as it is in this case.
+
+As for why Mercurial was chosen over Bazaar, it came down to
+popularity.  As the core developer survey shows, hg was preferred over
+bzr. But the community also appears to prefer hg as was shown at PyCon
+after git's removal from consideration was announced. Many people came
+up to Brett and said in various ways that they wanted hg to be chosen.
+While no one said they did not want bzr chosen, no one said they did
+either.
+
+Based on all of this information, Guido and Brett decided Mercurial
+was to be the next version control system for Python.
+
+
+Transition Plan
+===============
+PEP 385 outlines the transition from svn to hg.