290
《Git版本控制管理（第2版）》——1.3 先例
本节书摘来自异步社区《Git版本控制管理（第2版）》一书中的第1章，第1.3节，作者：【美】Jon Loeliger , Matthew McCullough着，更多章节内容可以访问云栖社区“异步社区”公众号查看
1.3 先例
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引入了双向差异的概念，来提高文件不同版本的存储效率。
并行版本系统（Concurrent Version System，CVS）由Dick Grune于1986年设计并最初实现。4年后又被Berliner和他的团队融入RCS模型重新实现，这次实现非常成功。CVS变得非常流行，并且成为开源社（http:www.opensource.org）区许多年的事实标准。CVS相对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也同时实现了这个概念。
最后更新：2017-06-01 17:01:34