加入弃用 Mercurial 浪潮，PyPy 宣布成功迁移到 Git、GitHub

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

继 Firefox 浏览器之后，PyPy 社区也宣布放弃 Mercurial 分布式版本控制系统而是选择将 PyPy 规范存储库和问题跟踪器迁移到 GitHub 上（https://github.com/pypy/pypy）。随着时间的推移，弃用 Mercurial 呼声与行动愈发高涨。

动机

作为一种非常兼容的 Python 解释器，PyPy 成为 CPython 快速且功能强大的替代品，深受开发者的欢迎。

现如今之所以选择将存储库迁移到 GitHub，PyPy 社区给了出了详细地解释：

• Mercurial 是一个更好的版本控制系统，命名分支模型和用户界面都非常出色。但原有的存储库地址 foss.heptapod.net（https://foss.heptapod.net/pypy/pypy）在 Google、Bing、duckduckgo 等搜索引擎中的索引不够完善，因此用户发现在项目中搜索问题更加困难。

• 由于 Heptapod 已加强其垃圾邮件控制，PyPy 社区收到报告称，用户创建问题只是为了将它们标记为垃圾邮件。

• 开源已经成为 GitHub 的代名词，而 PyPy 规模太小了，无法改变这一点。

• 当前社区所做的许多开发都是为了解决用户遇到的问题。如果所有的代码都在同一个平台上，那么跟踪联锁问题会更容易。

• FAQ 提出了两个反对迁移的论点。GitHub Notes 解决了第一个观点的许多问题：查找提交来源的困难，尽管并非完全解决。但主要问题在于第二点，事实证明不迁移到 GitHub 会阻碍贡献和问题报告。

• 希望继续使用 Mercurial 的人可以使用下面的方法推送到 GitHub。

• GitHub 比 foss.heptapod.net 拥有更丰富资源。PyPy 社区添加了一些 CI 作业以替代一些陈旧的 buildbot 基础设施。

方法

在此，PyPy 团队也在博客上分享了具体的迁移方法，希望对想要将自家存储库从 Mercurial 迁移到 GitHub 的开发者带来一些参考。

迁移包括两个部分：迁移代码，然后迁移问题和合并请求。

代码迁移 1：代码和注释

该团队使用了 git-remote-hg 的一个分支来创建一个本地 Git 存储库，其中包含所有的变更集。然后，PyPy 开发者 Matti 表示，想为每个提交添加一个 Git 注释，注明它来自哪个分支。

因此，该团队准备了一个包含两列的文件：Git 提交哈希和来自 Mercurial 的相应分支。Mercurial 可以通过两种方式描述每个提交：通过提交哈希或通过一个数字索引。PyPy 团队使用 hg log 将索引 i 转换为 Mercurial hash，然后使用git-remote-hg 的 git-hg-helper 将 Mercurial 哈希转换为 Git 哈希。

$(cd pypy-git; git-hg-helper git-rev $(cd ../pypy-hg; hg log -r $i -T"{node}\n"))

然后，PyPy 团队再次使用 hg log 打印索引 i 的 Mercurial 分支：

$(cd pypy-hg; hg log -r $i -T'{branch}\n')

将这两者结合起来，PyPy 团队可以通过它们的数字索引循环遍历所有提交，以准备这个文件。然后，该团队迭代文件中的每一行，并添加 Git 注释。由于 git note add 命令在当前 HEAD 上操作，其需要依次检出每个提交，然后添加注释：

git checkout -q  && git notes --ref refs/notes/branch add -m branch:

然后，该团队使用 git push --all 命令推送到 GitHub。

代码迁移 2：准备分支

PyPy 几乎有 500 个开放的分支。代码迁移创建了所有分支的 HEAD，但 git push --all 并没有将它们推送。PyPy 开发团队需要检出它们并逐个推送。因此，其创建了一个包含所有分支名称的文件。

cd pypy-hg; hg branches | cut -f1 -d" " > branches.txt

然后将每一个推送到 GitHub 存储库。

while read branch; do git checkout branches/$branch && git push origin branches/$branch; done < branches.txt

请注意，迁移时分支被命名为 branches/XXX，而不是 branch/XXX。这会导致合并请求的迁移出现混淆，稍后会详细介绍。

问题和合并请求的迁移

与此同时，该团队还使用了来自 node-gitlab-2-github（https://github.com/piceaTech/node-gitlab-2-github）的解决方案，它几乎完美地运行。

重要的是在私人存储库上进行转换，否则每次成功映射用户名称的提及都会通知用户有关转移。对于像 PyPy 这样具有 600 个合并请求和超过 4000 个问题的存储库来说，这可能相当烦人。问题迁移没有问题：脚本正确保留了问题编号。然而，该脚本不会将 Mercurial hash 转换为 Git hash，因此注释中的哈希将显示为没有指向提交的链接。合并请求则更为复杂：

• Mercurial 命名分支一旦合并就会“消失”，因此对已合并分支的合并请求在 Git 中找不到目标分支名称。转换会创建一个带有标签 gitlab merge request 的问题。

• 由于某种原因，由 git-remote-hg 创建的分支被称为 branches/XXX，而不是 GitLab 期望的 branch/XXX。这搞乱了合并请求/PR的转换。对于一些分支（打开的 PR 和主目标分支），该开发团队手动创建了额外的不带 es 的分支。最终结果是，打开的合并请求变成了打开的 PR，已合并的合并请求变成了问题，而关闭但未合并的合并请求未被迁移。

分层转换

PyPy 已经从 Bitbucket 迁移到 Heptapod 一次。许多问题反映了多次迁移：它们在第一次迁移中包含诸如“最初在 Bitbucket 上由 XXX 创建”的行，以及来自此次迁移的额外行“在 Heptapod 上”。

下一步

虽然 GitHub 上的仓库已经上线，PyPy 团队表示还有一些事情需要做：

• 文档需要更新以适应新的仓库，readthedocs 的构建自动化也需要调整。

• wiki 应该从 Heptapod 复制过来。

• buildbot.pypy.org 也应该查看新的存储库。该团队希望代码足以与 Git 存储库进行交互。

• speed.pypy.org 跟踪变化，它也需要引用新位置。

• 为了保持对 Git 新提交的跟踪分支，该团队还启用了 Julian 创建的 github action，将 Git 分支注释添加到每个提交中。

• 一些合并请求没有被迁移。如果有人愿意的话，他们可以在解决分支命名问题后进行迁移。

最后，PyPy 也呼吁更多的开发者参与进来：

• 点亮这个存储库，让其他人知道如何找到它；

• 帮助修复一些已存在的问题或提出新的问题；

• 利用更熟悉的工作流方式参与项目；

• 提出改进迁移的建议：PyPy 社区是否遗漏了什么或者可以做得更好的地方？

原文地址：https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html

本文为 CSDN 翻译，未经授权禁止转载。

推荐阅读：

▶隐退三年，身价4800亿元的Google创始人出面，亲自给Gemini写代码，还经常加班到凌晨一点！

▶阿里被判赔偿京东 10 亿；2023 赚了 7700 亿，马斯克再次成世界首富；Vue 3.4 发布｜极客头条

▶ChatGPT 设计了一款芯片