译者 | 原子武器果汁、Tina
在 Git 当然的统治者下，你还提过 SVN 吗？
下月六月，GitHub 将从 GitHub.com 删掉 Subversion 全力支持，GitHub Enterprise Server 没多久后也将遵从此操作方式。
GitHub 是亚洲地区体量最小的 Subversion PS3，但那时即使保护生产成本和管理工具的演进，GitHub 已经开始出局这个服务项目。
GitHub 挥别 Subversion
GitHub 于 2010 年导入 Subversion 全力支持，那时候管理工具软件的新格局与那时有非常大的相同，绝大部分人采用的是有二十年产业发展产业发展史的封闭式管理工具系统 Subversion ，而 Git 则是一个信息时代。彼时，谁都没有预料到分布式系统管理工具最后会接手封闭式管理工具，更不能没人预料到 Git 会在二十年后产业发展成为非主流。
现如今，十一年早已往后，有仅约 94% 的开发者在采用Git，而 Subversion 比从前罕见得多。所以，依照 GitHub 的讲法，每一月多于 5000 个存储库接到 SVN 允诺，其中仅 0.02％的允诺透过 Subversion 西北侧推送。
GitHub 的联手创办人 Scott Chacon 罗亚尼则表示，“13 天前的万圣节，GitHub 正式发布了迄今为止最合适的万圣节回帖： SVN 在 GitHub 上全然需用。虽然它早已有了极短的产业发展史，但那时它总算要完结了。”
为此，有网民则表示吃惊：“GitHub 竟然到那时还全力支持 SVN？？”在 Git 后端上提供更多 SVN 并不是常见方式。比如说 GitHub 的老劲敌 GitLab 仅全力支持 Git 和最小的云服务商的代销服务项目 AWS CodeCommit、Cloud Source Repositories，而 Azure Repos 从未有过 Subversion 接口。
GitHub 停止 Subversion 全力支持也给其他企业敲响了警钟，Newfold Digital WP 战略负责人 Joost de Valk 跟评道：“GitHub 已经开始出局 Subversion 全力支持。也许是 WordPress 停止采用 Subversion 的时候了？”
为什么 Git 会成为管理工具市场上的囊中物？
依照 2022 年 Stack Overflow 开发者调查报告，对于目前的管理工具软件市场份额，Git 占据了约 94%，其次是 SVN (Apache Subversion) 和 Mercurial。
曾经有一段时间，SVN 和 Mercurial表现也很突出，相信很多有二十年以上开发经验的人会提过它们。只是现如今，很明显，Git 成为了当然的赢家。那时，让我们一起回忆一下管理工具的演进产业发展史吧。
Apache Subversion
Subversion（SVN）是一套开源管理工具系统，透过中央服务项目器进行源代码保护；任何打算变更代码的用户都可以透过客户端访问到这些文件。与 Git 采用的分布式系统模型相比，SVN 的客户端-服务项目器模型显得比较老派，变更会先被存储在本地，并在推送到上游代码仓库时被分发至中央产业发展史记录（及其他分支）。事实上，SVN 确实是以之前的管理工具为基础，最初就是想成为 CVS（并发版系统）的高兼容度继任方案。有些朋友可能不太熟悉，CVS 最初正式发布于 1982 年，属于管理工具系统（RCS）的一种前端和扩展。
上一代管理工具方案主要面向 10 到 15 天前的软件构建方式。彼时，软件会被构建成集中代码仓库，所添加的全部功能都被合并至单一主干当中。分支本身很罕见，即使有最后也会被吸纳进主干内。各种重要文件——特别是那些大型二进制文件——都可以进行“锁定”，防止其他开发者在我们处理的同时做出变更。另外，文件、分支、标签等一切都以目录的形式存在。这种模型非常适合集中工作的开发团队，最后成果就是特定的一个版，透过光盘或者下载链接的形式分发。
SVN 就是这种模型的免费开源版。作为付费型客户端-服务项目器管理工具系统的典型代表，Perforce 在大型企业（特别是谷歌）中具备一定吸引力；但对于不打算为此额外花钱的用户，SVN 是个不错的选择。不少小公司（包括我们自己）刚开始都会用封闭式管理工具来管理代码，这甚至成了很多开发团队的习惯和偏好。
但往后十几年间，工程组织的运作方式发生了颠覆性的变化。不再由中央开发团队在单一代码仓库上工作；那时我们面对的是多个独立团队，每一团队各自负责一项或多项服务项目。VonC 是一位管理工具专家，帮助很多企业摆脱了 SVN。他认为 SVN 是一种专为“敏捷性较为低下的工作方式”而设计的方案。“这早已妨碍到了管理、代码仓库的创建/注册、和常规开发工作流程。与之相对应的是，分布式系统模型在这些方面更加敏捷。我认为近期不断壮大的远程办公声势，将会进一步冲击这些封闭的环境系统。”
SVN 越来越无人问津的另一个原因，就是 Git 用事实证明了自己更好、更强。高级软件工程师 Quentin Headen 在刚开始工作那会曾用过 SVN。“在我看来，SVN 有两个致命缺点。首先，它采用封闭式设计，就是说 SVN 服务项目器必须处于运行状态才能接收开发者提交的变更。一旦互联网发生故障，麻烦就大了。第二点，分支是种负担。一旦创建了分支，就没法将其删掉（如果我没记错的话）。虽然有一条命令可以删掉分支，但它仍然会被保留在产业发展史记录中。Git 分支就更轻松易用，能在必要时直接删掉。”
很明显，随着新一代管理工具系统的诞生，SVN 失去了其优势地位。所以需要注意的是，彼时冲击 SVN 的绝不止 Git 这一位。
Mercurial
没错，Git 并不是分布式系统管理工具家族的唯一成员。Mercurial 与 Git 同样于 2005 年首次亮相，取得的江湖地位也在伯仲之间。但最后，天下尽归于 Git，这个相信大家早已看到了。
当初，Mercurial 似乎更照顾用过早期管理工具系统的开发者。VonC 指出，“这有点类似于 VHS 与 Betamax（两种磁带格式）之争。”
Mercurial 的核心开发者 Raphaël Gomès 和 Pierre-Yves David 提到，时至今日不少大型企业仍在以某种形式采用着 Mercurial，包括 Mozilla、Facebook（可能早已转移到 Mercurial 的 Rust 移植版，名为 Eden）、谷歌（在其 Piper 自定义管理工具方案中保留了部分 Mercurial 功能）、诺基亚和 Jane Street。
“现如今，Mercurial 的核心优势就是它能在体量极大的项目（处理数百万次提交和数百万个文件）上进行扩展。多年以来，众多公司在性能改进和专用功能方面做出贡献，这让 Mercurial 成为管理极大 monorepos 的可行选择。”
来自谷歌的 Ry4an Brase 解释了 Mercurial 仍具生命力的原因：“Git 早已与文件系统紧密结合。甚至 GitHub 也将代码仓库当成了磁盘上的文件进行访问。而大量用户针对单个代码仓库执行提交的并发需求，一定会超过文件系统的访问承载上限。谷歌和 Facebook 发现，Mercurial 能够适应这类数据存储需求，但 Git 不行。但随着 Git v2.38 和 Scalar 等近期正式发布的新成果，这种优势可能会逐步减弱。”
但 Mercurial 在吸引那些掌握大量 monorepos 的客户方面，还有另外一手绝活——可移植性与可扩展性。它是用 Python 编写的，所以不需要被编译生产成本地代码。只要具备 Python 解释器，它就能在任意操作方式系统上成为可行的管理工具选项。Mercurial 还具有强大的扩展系统。Gomès 和 David 解释道，“扩展系统允许用户对 Mercurial 的各个方面做出调整，包括自定义行为或接入现有系统，这种灵活性在企业环境中非常受欢迎。”
现如今，Mercurial 仍然拥有不少铁杆粉丝。该项目也还是个挺活跃的项目，Gomès 和 David 仍然在做代码贡献、管理正式发布周期，并举办年度会议。虽然算不上市场领先的工具，但 Mercurial 牢牢守住了自己的一席之地。
为什么 Git 能笑到最后？
纵观 2022 年版控制领域的基本新格局，其实不难理解为什么分布式系统管理工具成了软件开发者们的首选方案。但是，为什么 Git 的市场份额会比 Mercurial 大那么多？它们的诞生时间相似、功能配置接近，颇有种既生瑜、何生亮之感。Brase 给出的理由是，“对于个人项目，我会选择 Mercurial。但如果是要创办一家公司，我会采用 Git 来避免重新培训和新人难上手等问题。”
Mercurial 当然也有自己的优势，SVN 用户对它的设计和封闭式操作方式会感觉非常熟悉。VonC 则表示，“Mercurial 其实上手更快、用起来感觉更熟悉，即使它跟 Subversion 有那么几分相似，只是采用了分布式系统模型。”但这种过于忠实旧时光的思路未必就是好事，“这也成了反对者拒绝 Mercurial 的理由，即使在去中心化开发成为非主流的今天，在分布式系统模型外面套上传统工具的壳子实在没什么必要。”
至于 Git 为什么能压倒性胜出，也许可以简单归结为强大的平台与可观的首发用户群体。Gomès 和 David 坦言，“Mercurial 之所以在 2010 年代之初输给了 Git，一方面是即使彼时 GitHub 的飞速产业发展，另一方面是即使 Linux 社区对 Git 拥有天然认同。”
虽然 Mercurial 最初也占据了一点有利位置，但随着时间推移，这种优势逐渐消散。Brase 认为，“Mercurial 的最初定位是透过内置的 Web UI 提供更多精心设计且连贯顺畅的用户体验。GitHub 虽然没能为 Git 提供更多同等水平的 Web 用户界面和连贯性，但庞大的贡献者群体和创始者的感召力最后牢牢压制住了 Mercurial。”
庞大贡献者群体所对应的，自然就是“雪崩”般的功能正式发布；再加上对用户需求的关注，无疑让 Git 顺利斩获可观的市场份额。近 15 天前，曾经没人将 Git 比作是“百战天龙”（特别擅长用身边小物件达成意外惊喜的特工片主角），而 Mercurial 则更像“007”。只要熟悉命令行，那 Git 能帮我们为几乎一切问题拼凑出定制化解决方案；而 Mercurial 相对更挑工作，如果合适则更加快速高效。面对现状，他的最新观点是“我当初对 Git 的用户界面最不满意，但它在多年的产业发展中逐步做出了改进（我那时用的是基于 Emacs 的 Git 前端，体验很好）；而 Mercurial 的主要缺点是在大型代码仓库上执行程度很慢，所以直到那时也没能解决。”
与“百战天龙”中的 MacGyver 一样，Git 一直在即兴发挥、迎接挑战。而如同 007 的经典男主 James Bond，Mercurial 也坚持着自己的行事风格——在某些情况下效果很好，但有时候则相当拉胯。Brase 认为，“我们可以透过一个例子来体会 Git 和 Mercurial 在处理新功能时的差别，即「config」命令。「git config」和「hg config」都是用于编辑用户邮件地址等设置的命令。「git config」命令会自动为用户修改「~/.gitrc」，所以大多数情况下是正确的。Mercurial 的缔造者则坚决拒绝一切会编辑配置文件的提交贡献。相反，「hg config」只会在「~/.hgrc」上启动文本编辑器。这就像在嘲讽我们，被文本配置文件吓倒的程序员，就像是会晕血的医生——统统不合格。”
总而言之，虽然 Git 好像早已成了管理工具市场上的囊中物，但这个世界总有更多解决问题的办法，如果大家对目前的某些选项感到沮丧，不妨再多探究一番。一定还有别的途径，一定还有其他值得学习的新思路。
参考链接：
https://www.infoq.com/news/2023/02/github-subversion-svn/
https://survey.stackoverflow.co/2022/#version-control-version-control-system
https://stackoverflow.blog/2023/01/09/beyond-git-the-other-version-control-systems-developers-use/
https://www.infoq.cn/article/9W1zPkwUqT1Zyx0QGt3J
