版本控制工具历史的10个里程碑

     <p> 英文原文：<a href="/misc/goto?guid=4958333392061896772" rel="nofollow" target="_blank">frabcus </a></p>    <p> 引言：</p>    <blockquote>     <p>“如果你想要了解真正的历史，你需要回到在打孔卡上进行人工比对的年代。” —— <a href="/misc/goto?guid=4958333392855628762" rel="nofollow" target="_blank">Jim Rootham</a></p>    </blockquote>    <p> 在这个<a href="/misc/goto?guid=4958333393664499330" rel="nofollow" target="_blank">为鳕鱼编写传记</a>都能够流行的年代，写一本记录程序员如何存储代码——他们最重要的劳动成果的书一点也不疯狂。</p>    <p> 既然你和我都没有时间来阅读或编写这样的一本书，我们打算用这篇博客来进行探讨。</p>    <p> 这是一个重要的问题。</p>    <p> （现在）<a href="/misc/goto?guid=4958184186834948584" rel="nofollow" target="_blank">版本控制产品</a>非常普通而且很流行。</p>    <p> 然而，它经历了几十年的不断创新。在这个领域里最聪明的人的努力下，代码管理变得非常简单而且有效。</p>    <p> 每一步都是那么让人感到<em>惊奇</em>。</p>    <p> <strong>1. 源代码就是一个文本文件！（20世纪 60 年代）</strong></p>    <p> 现在看来，存储源代码和编写简单文档应该是一样的。但如果你简单读一下 <a href="/misc/goto?guid=4958333395205934830" rel="nofollow" target="_blank">ASCII 的历史</a>就会知道，即使达成这样的共识也来之不易。</p>    <p> <strong>2. 人们可以手动跟踪代码版本！（20世纪 60 年代）</strong></p>    <p> 在没有软件的年代，所有事情都要从源代码开始。</p>    <blockquote>     <p>“我工作的第一家公司有一个源码管理部门。当你把代码写好以后，将软盘交给源码管理部门一位漂亮女士。他们会及时更新函数库，用你的磁盘基于公司官方的代码构建产品交付给客户。” ——  <a href="/misc/goto?guid=4958333396001721556" rel="nofollow" target="_blank">Miles Duke</a></p>    </blockquote>    <p> <strong>3. 你可以为单个文件保留多个版本！（1972，1978）</strong></p>    <p> 采用奇特的交错编织文件格式，SCCS 在版本控制领域称雄了 10 年之久。</p>    <p> 记录单个文件的从一个版本到下一个之间的变化花费了几年的时间。<a href="/misc/goto?guid=4958333396806332025" rel="nofollow" target="_blank">“差异文件比较算法”</a>是这个课题最近发表的一篇论文（1976）。</p>    <p> 1982年，RCS 反向使用 diff 文件（<a href="/misc/goto?guid=4958333397611241572">描述算法原文</a>）打败了 SCCS 成为继任者，并让评论家大跌眼镜：</p>    <blockquote>     <p>“一起出现的还有带有反向比较功能的 RCS，我认为它非常棒。” —— 无名氏</p>    </blockquote>    <p> <strong>4. 每个人都可以检出自己的拷贝！(1982)</strong></p>    <p> 在那个时候，人们工作时需要登录一台中央大型机并通过它一起工作。采用符号链接，RCS 可以让每个人都工作在相同版本的代码上，而且每个人都有自己的工作拷贝。</p>    <blockquote>     <p>“有一个叫做 RCS 的文件，实际上它十一个链接到 RCS 仓库的符号链接，你可以与其他小组成员一起使用。”  —— 耶鲁大学 <a href="/misc/goto?guid=4958333398407849907" rel="nofollow" target="_blank">RCS 使用介绍</a></p>    </blockquote>    <p> <strong>5. 喔！你可以一次给多个文件进行版本控制！（1986）</strong></p>    <p> 令人吃惊的是，直到 CVS 出现之前，版本控制系统都只支持单个文件。当然，你可以使用通配符让 RCS 提交多个文件或者标记特定分支。但这些并不是版本控制系统的一部分。</p>    <p> CVS 默认会递归修改所有文件。突然之间，软件从单个目录或文件变成了文本文件的递归树。</p>    <p> 虽然由于不具备“原子性”导致实现的产品不尽如人意（后来 Subversion 在 2000 年解决了这个问题），但是瑕不掩瑜。</p>    <p> <strong>6. 两个人可以同时编辑同一个文件，并将他们的工作合并在一起！（1986）</strong></p>    <p> 20世纪 90 年代末，我在 <a href="/misc/goto?guid=4958333399220214990" rel="nofollow" target="_blank">Creature Labs</a> 工作。我们从 Visual SourceSafe（商业软件，微软公司发布）转到 CVS（开源软件，由一些嘻皮士发布）。</p>    <p> 坦率的讲，大家都怀疑 CVS 能否做到它宣称的那样：让多个人同时编辑同一个文件，并将他们的修改没有错误地合并到一起而不造成其他问题。</p>    <p> 在我们开发 <a href="/misc/goto?guid=4958333400010866404" rel="nofollow" target="_blank">Creatures 3</a>的时候，SourceSafe 的互斥锁成为了一个大问题。我们当时要添加垃圾搜集功能，这个功能会影响到几乎所有的代码。这个时候，我们的首席程序员不得不在周末检出每一个文件然后进行修改。</p>    <p> 1986年的<a href="/misc/goto?guid=4958333400811634306" rel="nofollow" target="_blank">这篇论文</a>记录下了这个奇迹。当 Dick Grune 和他的团队在荷兰开发一个编译器的时候，他们遇到了同样的问题，CVS 从此应运而生。</p>    <p> <strong>7. 可以在远程服务器上共享代码仓库！（1994）</strong></p>    <p> 大多数时候，人们只在一台机器上使用版本控制。在 1986 年，人们可以通过 RCS 的一些版本以及 CVS 提供的远程文件共享机制以拥有远程代码仓库。</p>    <blockquote>     <p>“假如 RCS 的某个版本可以通过远程服务器访问，那么开发人员就可以在代码仓库之外的机器上进行开发了。”  —— <a href="/misc/goto?guid=4958333400811634306" rel="nofollow" target="_blank">Dick Grune</a></p>    </blockquote>    <p> 然而，直到 1994 年 TCP/IP 协议的引入，这个想法才得以起步。</p>    <blockquote>     <p>“直到 Cygnus 软件的 Jim Blandy 和 Karl Fogel（这两位后来成为 Subversion 项目的主要开发者）为 CVS 发布了一些补丁，使得 CVS 客户端软件可以通过远程 TCP/IP 连接进行访问，CVS 才真正变得无处不在。 ”—— <a href="/misc/goto?guid=4958333402351605168" rel="nofollow" target="_blank">Eric Raymond</a></p>    </blockquote>    <p> <strong>8. 免费的开源版本控制主机服务！(1999）</strong></p>    <p> 这并不是源码管理技术的进步，但这的确是一个标志，Internet 社区的发展与技术的进步同等重要：</p>    <blockquote>     <p>“OSS 以及成为历史，这已经成为一种趋势。John T. Hall 预见到，如果项目都是在线开发，那么之前开发的版本就在那里。开发平台服务是一种创新，但是没有人去做，我们就想‘为什么不呢？’”—— <a href="/misc/goto?guid=4958333403169929100" rel="nofollow" target="_blank">Brian Biles</a></p>    </blockquote>    <p> 就像末日狂欢那样（因为股票的原因），VA Linux 把 SourceForge 带到了这个世界上。这对新项目是天大的好消息（例如我的 <a href="/misc/goto?guid=4958333403982429214" rel="nofollow" target="_blank">TortoiseCVS</a>）。</p>    <p> 在当时，在 Internet 上获得一台服务器很困难而且非常昂贵，进行源码管理和 bug 追踪也是如此。这项新服务尽管缺乏商业模式，却让无数项目更早地面世。</p>    <p> 译注：OSS：一个综合的业务运营和管理平台，同时也是真正融合了传统 IP 数据业务与移动增值业务的综合管理平台。</p>    <p> <strong>9. 没有主代码库，你可以向所有人发布！（2005）</strong></p>    <p> 在 21 世纪头 10 年，有一股将版本控制实现完全分布式的潮流。</p>    <p> 也就是说，在你本地的机器上存放的是一份完整的代码历史，可以轻易地与任何其他拷贝进行分支和合并。顺带说一下，也正是这个特性使得分支和合并变得更加容易。</p>    <p> 我并没有记录某个第一次发明这种工具，而是按照它产品化以及流行的时间进行统计。鉴于此，将它定在 2005 年似乎有些不公平。Mercurial 和 Git 发布于 2005 年 4 月。</p>    <p> 这篇“<a href="/misc/goto?guid=4958333404796703579" rel="nofollow" target="_blank">分布式版本控制风险</a>”（2005年底）介绍了这个革命性的创新。</p>    <p> <strong>10. 当你检出一个 fork，你可以让大家都看到！（2008）</strong></p>    <p> GitHub 的成功有很多原因（尽管我之前<a href="/misc/goto?guid=4958333405589917885" rel="nofollow" target="_blank">提到过一些</a>，要讲清楚这个问题还是需要单独写一篇文章讨论）。</p>    <p> 关键在于，你可能甚至可以将一些自己做的不大的改动提交到别人的公共代码上。在 GitHub 之前，一般我们会保存在自己的电脑上。</p>    <p> 如今，只需要简单做一个 fork，或者甚至<a href="/misc/goto?guid=4958333406388765419" rel="nofollow" target="_blank">可以直接在浏览器上编辑</a>，这样任何人都可以马上发现你代码中的 bug。</p>    <p> <strong>尾声</strong></p>    <p><strong> </strong></p>    <p> 快速回顾一下这几十年的进展。是的，计算机的发展做出了贡献。但更主要的是，这些都是人们为更好地协作而贡献出的聪明才智。</p>    <p> 这让我想到，下一个会是什么？在版本控制领域还会有什么令人惊叹的事情发生？</p>    <p> 推而广之，同样的事情会在其它领域发生吗？</p>    <p> 作为核心信息基础设施，这种巨大的改进能够最终改善政府、医疗、新闻或者数据领域创新的障碍吗？</p>    <p> 我有这种感觉，我们就要找到答案了。</p>    <p> 想了解更多吗？请阅读<a href="/misc/goto?guid=4958333407182630551" rel="nofollow" target="_blank">《版本控制时间轴》</a>（发表于 Plastic SCM 的博客，不要忘记看一下评论）以及<a href="/misc/goto?guid=4958333407981746785" rel="nofollow" target="_blank">《理解版本控制系统》</a>（作者 Eric Raymond）</p>    <p> 编译：<a href="/misc/goto?guid=4958185140659301754" target="_blank">伯乐</a>在线 – <a href="/misc/goto?guid=4958327305355149094">唐尤华</a></p>