版本控制系统或资源管理系统是现代软件研发的一个重要方面。不使用版本控制系统就如同超速驾驶一辆汽车:很刺激,也可能会更快抵达目的地,但事故却在所难免。本文概述了软件配置管理(SCM)系统及其优势,内容涵盖 CVS、Subversion、Arch 和 Git。本文还讨论了最常见的 SCM 体系结构。本文在最后给出了新出现的一些方法及这些方法和先前方法的区别。

什么是软件配置管理?

在学校学习的重要工具中,通常不会 包含 SCM。软件(或资源)控制,正如其名字所暗示的那样,是一种工具和一种相关的过程,而这种过程被用于维护源代码及其演进。SCM 提供的主要功能如下:

  • 在存储库(repository)中维护一个文档。
  • 在存储库中维护文档的修订。
  • 检测源更改冲突并为多个研发人员的环境提供合并。
  • 跟踪变更的发起方。
  • 为了实现一致、可重复的构建提供文档(相关修订)的配置管理。
SCM 的适用性
资源控制 主要是指源代码和相关文档的控制,而资源管理 则可应用于任何类型的资源。包含超文本标记语言(HTML)和二进制图像文档、一般文本文档或其他任何文档的 Web 站点是 SCM 系统进行修订控制的对象。

所以,SCM 允许您控制存储库中的一组文档并跟踪这些文档的修订。其他研发人员更改了存储库中的这些文档后,SCM 会标识出这些变更和您所做的变更之间存在的冲突,然后自动将其合并或通知您存在冲突。这个功能很重要,因为他允许多个研发人员修改同一组文档。SCM 还能跟踪出谁做了何种变更。SCM 还允许您将文档按逻辑划分为相关的文档组,比如组成软件图像或可执行文档的源文档。

SCM 的术语

在深入研究 SCM 体系结构的类型和细节之前,先要熟悉一下术语的含义。存储库 是文档存储和管理的中央位置(有时又被称为)。从存储库中取出文档放到本地系统的工作文档夹的过程被称作签出。假如变更了本地文档而又想同步变更存储库,就需要执行更新。假如要将变更后的文档签入到存储库,就需执行提交。假如所变更的文档先前已被变更并已由别人提交,则会发生合并,表明两组变更集将会被合并在一起。若由于变更冲突的原因不能合并时,则必已发生了冲突。在此情况下,提交被拒绝,并需要研发人员手工合并变更。当提交了变更之后,就会创建此文档的一个新的修订

一个或多个研发人员能够对主树(存储库的当前头)或位于主树旁的单个的分支进行操作。这就让研发人员能够操作分支而不会影响到主树。当分支稳定后,再将分支和主树进行合并。

要标记源树演进过程中的重要阶段,能够对一组文档修订应用标签。这会将这组文档组合成一个有用的集合(有时会用作针对于惟一构建的文档的一个发布)。

体系结构

各种 SCM 间有许多的差异,其中有两种最基本的区别很值得研究:

  • 集中式存储库和分布式存储库
  • 变更集模型和快照模型

集中式存储库和分布式存储库

现代 SCM 体系结构的最为重要的差异之一是存储库是集中式的还是分布式(分散的)。当前最为常见的体系结构是集中式存储库。这个星型 体系结构由中央的源存储库和工作于这个存储库的多个研发人员组成(参见图 1)。研发人员从中央存储库签出源代码到本地的沙箱内,进行变更后,将他提交回中央存储库。其他研发人员就能够再访问这些变更。


图 1. 在集中式体系结构中,任何研发人员都通过同一个中央存储库进行工作
集中式的 SCM 体系结构

中央存储库也能够创建分支,允许多个研发人员协作于针对位于存储库(但必须在 mainlinetip 之外)的资源的一组变更。

分布式体系结构则允许研发人员为其变更创建其自己本地的存储库。本地研发人员的存储库和原始的存储库(已被分布)很相似。主要的区别是:在集中化的方式中,变更是在沙箱内完成的,而在分布式方法中则允许研发人员工作于分离的存储库。研发人员进行变更、提交变更到其本地的存储库,之后,在不影响主干的前提下,和其他研发人员的变更合并。这样,本地研发人员就使得变更集对上线(upline)研发人员可用(参见图 2)。


图 2. 在分散体系结构中,研发人员通过其各自的存储库员同步工作
分散的 SCM 体系结构

分散体系结构很有意思,因为他允许不同的研发人员在对等网络内同步工作。当工作准备好(最好是稳定)后,研发人员能够分发变更集(或修补)以使他人也能够使用这些特性。这是当今许多开源系统的模型,包括 Linux® 内核。

变更集模型和快照模型

早先的和现代的 SCM 的体系结构的另一个有趣的区别是 delta 变更的存储方式。他们理论上是相同的,且产生的结果也相同,但在修订的存储方式上二者却大不相同。

文章整理:西部数码--专业提供域名注册虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢!