Subversion 曾经是我们亲密无间的战友，但自 从一年前部分团队成员去了美国，我们和 Subversion 的关系就开始出现了裂痕，首先是将 Subversion 服务器架设在美国后，中国开发人员频繁 进行的一些操作变得非常缓慢，本来通过追溯代码历史便可找出原因的问题，却因为网速缓慢，导致开发者将大量的时间耗费在等待服务器响应，而不是分析问题 上。其次，由于缺乏 IT 基础设施方面的投资以及完善的备份策略，数次因为网络原因或者服务器宕机，导致团队无法从中国访问版本管理服务器，正常的提交、更 新操作都无法进行，最严重的是版本管理服务器曾经在发布之前出现故障，导致服务器上的数据不得不回滚到九天以前，给发布带来了很大的风险。
从现象上看，版本管理服务器不在本地是遭遇速度瓶颈的主要原因，本质却是由于版本管理工具不能很好的根据团队的规模和结构伸缩。对我们而言，比较理 想的版本管理解决方案是在中美两地架设服务器，加快各个操作的执行速度，服务器之间自动同步来平衡两地对于速度和代码集成的要求。然而采用 Subversion 作为版本管理工具，决定了服务器仅能架设在一地。 SVK 可以解决部分问题，但它的缺陷太多，操作起来非常不便。我们所面临的备份问题则是由于在 Subversion 的设计中，所有的元数据仅仅保存在服务器上，一 旦服务器出现意外，元数据所包含的宝贵信息便无从恢复。之前的教训让我们认识到如果采用 Subversion 作为版本管理工具，就不能仅仅乐观的假设服务 器不会出错，必须有详尽可行的备份计划，通过不断备份来规避风险。
Subversion 的这些天生缺陷让我们把目光投向了 DVCS （分布式版本管理工具），在这个家族中，比较成熟的产品有 Git 、 Mercurial 和 Bzr ， 相比之下，由于 Mercurial 对 Linux，Mac 和 Windows 平台有良好的支持，支持通过 Web 方式访问代码库，并存在成熟的 IntelliJ、Eclipse 插件，最终成为了胜出者，时至今日，它已经在我们团队服役超过 1 年了，从 0.9.4 到 1.1.2，每一次版本的更新，都 让我们愈加喜欢这个设计精巧产品。那么较之 Subversion，Mercurial 究竟胜在哪里？
详细内容，请阅读全文：为什么我们要放弃 Subversion 。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论