《Git版本控制管理（第2版）》——1.3 先例

本节书摘来自异步社区《git版本控制管理（第2版）》一书中的第1章，第1.3节，作者：【美】jon loeliger , matthew mccullough著，更多章节内容可以访问云栖社区“异步社区”公众号查看

vcs的完整历史已经超出了本书的讨论范围。然而，有一些具有里程碑、革新意义的系统值得一提。这些系统对git的开发或者有重要的铺垫意义，或者有引导意义。（本节为可选章节，希望能够记录那些新特性出现的时间，以及在自由软件社区变得流行的时间。）

源代码控制系统（source code control system, sccs）是unix②上最初的几个系统之一，由m. j. rochkind于20世纪70年代早期开发。[“the source code control system,” ieee transactions on software engineering 1(4) (1975): 364-370.]这是有证可查的可以运行在unix系统上的最早的vcs。

sccs提供的数据存储中心称为“版本库”（repository），而这个基本概念一直沿用至今。sccs同样提供了一个简单的锁模型来保证开发过程有序。如果一个开发人员需要运行或者测试一个程序，他需要将该程序解锁并检出。然而，如果他想修改某个文件，他则需要锁定并检出（通过unix文件系统执行的转换）。当编辑完成以后，他又可以将文件检入到版本库中并解锁它。

修订控制系统（revision control system，rcs）由walter f. tichy于20世纪80年代早期引入[“rcs: a system for version control,”software practice and experience 15(7) (1985): 637-654.]。rcs引入了双向差异的概念，来提高文件不同版本的存储效率。

此外，cvs引入了一个关于“锁”的新范式。而之前的系统需要开发人员在修改某个文件之前先锁定它，一个文件同时只允许一个开发人员进行修改，所有需要修改这个文件的开发人员需要有序等候。cvs给予每个开发人员对于自己的私有版本写的权限。因此，不同开发人员的改动可以自动合并，除非两个开发人员尝试修改同一行。如果出现修改同一行的情况，那这一行将会作为“冲突”被标记出来，由开发人员手动去解决。这个关于“锁”的新规则使得多个开发人员可以并行地编写代码。

就像经常发生的那样，对cvs短处和缺点的改进，促进了新vcs的诞生：subversion（svn）。svn于2001年问世，迅速风靡了开源社区。不像cvs，svn以原子方式提交改动部分，并且更好地支持分支。

bitkeeper和mercurial则彻底抛弃了上述所有解决方案。它们淘汰了中心版本库的概念，取而代之的，数据的存储是分布式的，每个开发人员都拥有自己可共享的版本库副本。git则是从这种端点对端点（peer to peer）的模型继承而来。

最后，mercurial和monotone首创了用散列指纹来唯一标识文件的内容，而文件名只是个“绰号”，旨在方便用户操作，再没有别的作用。git沿用了这个概念。从内部实现上来说，git的文件标识符基于文件的内容，这是一个叫做“内容可寻址文件存储”（content addressable file store，cafs）的概念。这不是一个新概念。 据linus的说法③，git直接从monotone借用了这个概念。mercurial也同时实现了这个概念。