告别SVN，Git成独苗GitHub在13年后宣布淘汰Sub

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