版本控制系统

需要做出的第一个决定是主服务器端代码仓库的版本控制系统 (VCS)。目前，CPython 代码仓库以及许多支持库都使用 Mercurial。在评估 VCS 时，我们必须考虑 VCS 本身的功能，以及围绕该 VCS 的社区网络效应和影响力。

实际上只有两种选择，Mercurial 和 Git。在这两者之间，技术能力大致相当。因此，此 PEP 将主要忽略关于 VCS 系统的技术论据，而是关注社会方面。

无法获得使用特定 VCS 的项目或人员数量的确切数字，但是我们可以通过查看多个信息来源来推断哪些项目正在使用哪个 VCS。

Open Hub（以前称为 Ohloh）统计数据 [1] 显示，Open Hub 索引的代码仓库中有 37% 使用 Git（仅次于 SVN，占 48%），而 Mercurial 仅占 2%（仅领先于 bazaar，占 1%）。这使得 Git 在 Open Hub 上的流行程度是 Mercurial 的 18 倍以上。

另一个关于不同 VCS 流行程度的信息来源是 PyPI 本身。此来源更针对 Python 社区本身，因为它代表为 Python 开发的项目。不幸的是，PyPI 没有一个标准位置来表示此信息，因此需要手动处理。如果我们将搜索范围限制在 PyPI 上的前 100 个项目（按下载次数排序），我们可以看到其中 62% 使用 Git，22% 使用 Mercurial，而 13% 使用其他东西。这使得 Git 在 PyPI 上的前 100 个项目中比 Mercurial 的流行程度高出近 3 倍。

显然，从这些数字可以看出，Git 是开源项目中使用最广泛的 DVCS，选择更流行的 VCS 具有许多积极的好处。

对于新贡献者来说，这增加了他们已经学习了 Git 基础知识（作为另一个项目的组成部分）的可能性，或者如果他们现在才开始学习 Git，他们可以将这些知识应用到其他项目中。此外，更大的社区意味着更多的人编写使用指南、回答问题和撰写关于 Git 的文章，这使得新用户更容易找到他们试图学习的工具的答案和信息。

另一个好处是，由于具有更大的社区，因此会围绕它编写更多工具。这增加了从 GUI 客户端、辅助脚本、代码仓库托管等各方面的选择。

代码仓库托管

此 PEP 建议允许提交 GitHub Pull Requests，但是 GitHub 无法对不在 GitHub 上托管的代码仓库提交 Pull Requests。此 PEP 还建议除了 GitHub Pull Requests 之外，还可以使用 Phabricator 的 Differential 应用程序来提交提议的代码变更，并且 Phabricator 确实允许对不在 Phabricator 上托管的代码仓库提交代码变更。

因此，此 PEP 建议使用 GitHub 作为代码仓库的规范位置，并在 Phabricator 中创建一个只读镜像。如果将来某个时刻不再需要 GitHub，那么代码仓库托管可以轻松地迁移到 Phabricator 中，并且可以放弃接受 GitHub Pull Requests 的功能。

除了在 Github 上托管代码仓库外，所有代码仓库的只读副本也将镜像到 PSF 基础设施上。

代码审查

目前，CPython 使用 Rietveld 的自定义分支，该分支已修改为不在 Google App Engine 上运行，该引擎实际上只能由一个人维护。此外，它还缺少许多现代代码审查工具中存在的功能。

此 PEP 建议允许使用 Github Pull Requests 和 Phabricator 代码变更来提议代码变更并审查代码。它建议同时使用这两种方式，以便贡献者可以选择最适合他们提交代码变更的工具，并且审阅者可以选择他们最喜欢的工具来审查代码变更。

X 不是用 Python 编写的

当前工具（Mercurial、Rietveld）具有的一个功能是，所有部分的主要语言都是用 Python 编写的。此 PEP 认为，我们应该专注于最适合工作的工具，而不是恰好是用 Python 编写的工具。对于任何开源项目来说，志愿者时间都是宝贵的资源，我们可以通过关注工具本身的优缺点，而不是它们的作者用什么语言编写它们，来最有效地尊重和利用这种时间。

一个担忧是修改工具以适应我们的能力，但是这里的一个目标是不要修改软件以适应我们，而是将自己适应更标准的工作流程。这种标准化使得能够开箱即用地重复使用工具，从而释放开发人员时间来真正致力于 Python 本身，并使项目之间的知识共享成为可能。

然而，如果我们确实需要修改工具，Git 本身主要用 C 语言编写，与 CPython 本身相同。它也可以使用任何语言（包括 Python）为其编写命令。Phabricator 是用 PHP 编写的，PHP 在 Web 世界中非常常见，并且很容易上手。GitHub 本身主要用 Ruby 编写，但由于它不是开源的，因此无法修改它，所以它的实现语言完全没有意义。

GitHub 不是免费/开源的

GitHub 是这个提案的重要组成部分，有些人可能出于意识形态而非实用性的原因而反对这个 PEP。这个 PEP 认为，虽然使用完全的自由/开源软件是一个有吸引力的想法，也是一个崇高的目标，但通过为贡献者提供维护良好且他们已经了解或可以学习并应用于其他项目的良好工具来珍惜他们的时间，比将是否为自由/开源软件视为硬性要求更重要。

然而，历史已经告诉我们，有时仁慈的专有公司可能会停止仁慈。这可以通过几种方式来规避。

• 我们没有使用 GitHub Issue Tracker，既因为它对于 CPython 不够强大，而且因为对于主要的 CPython 仓库来说，如果我们有朝一日需要离开 GitHub，将我们的问题转移到其他地方的能力取决于 GitHub 继续允许 API 访问。
• 我们正在使用 GitHub Pull Request 工作流程，但所有这些更改都存在于 Git 内部。因此，GitHub 仓库的镜像可以轻松包含所有这些 Pull Request。如果 GitHub 突然变得“邪恶”，我们可能会失去任何评论，但更改本身仍然存在。
• 我们正在使用 GitHub 仓库托管功能，但由于这只是 git，因此离开 GitHub 就像将仓库推送到其他位置一样简单。仓库本身的数据可移植性极高。
• 我们还使用 Phabricator 为那些不想使用 GitHub 的人提供替代方案。这也作为一个后备选项，如果我们有朝一日需要停止使用 GitHub，它已经到位。

除了平台本身的优势之外，依赖 GitHub 还带来了一些好处。由于它是一家商业支持的企业，它拥有全职员工负责维护其服务。这包括确保它们保持正常运行，确保它们针对各种安全漏洞进行修补，并随着时间的推移进一步改进软件和基础设施。

Mercurial 比 Git 好

Mercurial 或 Git 在技术层面上是否更好是一个高度主观的问题。这个 PEP 没有说明 Git 或 Mercurial 的机制哪个更好，而是关注这两种选项可用的网络效应。由于这个 PEP 建议切换到 Git，这会将那些更喜欢 Mercurial 的人排除在外，但这些用户可以通过使用 Mercurial 的 hg-git [2] 扩展来轻松继续使用 Mercurial，该扩展允许它与服务器端为 Git 的仓库协作。

CPython 工作流程太复杂

在之前的讨论中，有一种观点认为 CPython 的多分支模型对于 Github Pull Request 太复杂了。这个 PEP 认为这种说法是不准确的。

目前，任何特定更改都需要手动为 2.7 和 3.x 创建补丁，这方面不会有任何改变。

如果有人提交了针对当前稳定分支（目前为 3.4）的修复程序，则可以使用 GitHub Pull Request 工作流程在浏览器中创建 Pull Request 以将当前稳定分支合并到主分支（假设没有合并冲突）。如果有合并冲突，则需要在本地处理。这比当前情况有所改进，在当前情况下，合并必须始终在本地进行。

最后，如果有人提交了针对当前开发分支的修复程序，那么如果希望将其也包含在稳定分支中，则必须手动将其应用于稳定分支。这也必须在新的工作流程中在本地进行，但对于较小的更改，可以在 GitHub Web 编辑器中轻松完成。

从这一点来看，我不相信任何系统能够隐藏维护多个长期运行分支所涉及的复杂性。工具所能做的只是尽可能轻松地提交更改。