1.定义

版本控制(Revision control)是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。

2.原理

版本控制透过文档控制（documentation control）记录程序各个模组的改动，并为每次改动编上序号。这种方法是工程图（engineering drawings）维护（maintenance）的标准做法， 它伴随着工程图从图的诞生一直到图的定型。 一种简单的版本控制形式，例如，赋给图的初版一个版本等级“A”。当做了第一次改变后，版本等级改为“B”，以此类推等等。

3.特征

1.软件系统的版本控制是指可以自行运行的各子系统的版本控制。

2.软件系统的版本号由评测小组的人员确定，由评测小组进行版本控制工作。

3.软件系统的版本号由3部分构成，即主版本号+次版本号+修改号。主版本号1位，只有当系统在结构和功能上有重大突破改进后才发生变化；次版本号有2位；修改号8位，采用提交时的日期，当系统进行任何修改后，包括数据库结构发生变化，修改号都要随之改变。例如：Ver3.31.19990317

4.各子系统的版本号独立。

5.各软件系统应该有显示详细版本号的功能。例如help菜单下的about功能。系统提交存档时，评测服务部要进行版本号检查。

6.新系统开发完成、或已存档的系统进行修改，修改完成后，进行提交存档时，由评测评测小组系统分析工程师确定新版本号、或更改版本号。

7.软件系统，产生新的版本后，老版本的软件系统是否继续保存，取决于以下条件：

a.老版本的系统如果有客户还在使用，在客户升级以前，必须继续保存。

b.老版本的系统已经没有客户使用了，并且新版本的系统已经把老系统的文档完整地升级过来，这样可以删除或覆盖老版本的系统资源。

c.对于要删除或覆盖的老版本系统，可以统一备份起来。

4.常用的版本控制优缺点

VSS

Visual SourceSafe：微软的版本控制工具，仅支持Windows操作系统。虽然简单好用，但是仅适用于团队级开发，不能胜任企业级的开发工作。

VSS优点：安装、配置、使用均较简单，很容易上手使用；操作简单，容易掌握；权限划分可到文件夹级，有Read、Check-Out & Check-In、Add/Rename/Delete、Destroy四种权限级别。

缺点：权限管理基于文件共享形式，只能从文件夹共享的权限设定对整个库文件夹的权限，而且必须要有可写权限；版本管理和分支管理只能靠人为的手工设置；版本发行时，只能手工挑选对应的版本文件进行发布；安全性不高，基于文件系统共享实现对服务器的访问，需要共享存储目录，这样用户可以对VSS的文件夹执行删除操作。

CVS

CVS是一个典型的服务器/客户端软件，有Unix版本的CVS 、Linux版本的CVS和Windows版本的CVS。CVS支持远程管理，项目组分布开发时一般都采用CVS。安装、配置较复杂，但使用比较简单，只需对配置管理做简单培训即可。安全性高，CVS服务器有自己专用的数据库，文件存储并不采用 “共享目录”方式，所以不受限于局域网。CVS可以跨平台，支持并发版本控制，而且免费。CVS不支持文件改名，只针对文件控制版本而没有针对目录的管理,并且缺少相应的技术支持，许多问题的解决需要自已寻找资料，甚至是研究源代码。但也可以根据自己的需要进行编程。

相对功能单一、简陋，适用于几个人的小型团队，在数据量不大的情况下，性能可以接受。

SVN

SVN（Subversion） 是一种版本管理系统，其前身是CVS。SVN是根据CVS 的功能为基础来设计的，它除包括了CVS 的大多数特点外，还有一些新的功能，如：文件目录可以方便的改名、基于数据库的版本库、操作速度提升、权限管理更完善等。

CVS与SVN比较

ClearCase（闭源集中式）

ClearCase提供了全面的配置管理——包括版本控制、工作空间管理、建立管理和过程控制，而且无须软件开发者改变他们现有的环境、工具和工作方式。

ClearCase包括两套：ClearCase LT和ClearCase (MultiSite)。前者可以用于在同一个局域网的开发小组，适合于中小型开发组织；ClearCase (MultiSite)则适应于分布于不同地理位置、不同局域网的开发小组，适合于大型的开发组织。

优势:

增加团队效率――通过对并行开发的支持来实现，包括图形比较和归并、标签、版本目录结构。

增加个人效率 ――通过自动的工作空间管理来实现，如：直接的版本访问、消除了在拷贝文件上的时间的浪费。

简单的维护和提高对客户的支持――通过快速准确的重建先前的版本来实现。

快速准确的产品发布 ――通过保证构造的准确性和对软件的每一个元件进行版本控制来实现。

减少错误发生 ――通过事件发生以后对每一个元件的变更进行追踪来实现。

硬件资源的优化 ――通过分布式构造、减少文件拷贝、可用对象的共享等功能来实现。

提高项目协调和编制 ――通过文件注释和开发周期阶段变更的自动关联来实现。

提高产品质量 ――通过灵活的进程控制，和图形接口定制，使得软件开发在实际中保持一致。

更加有效的团队扩展――通过减少系统管理和维护的负担来实现。

支持分布式结构使得团队成长――通过Client/Server结构进行多点复制和及时的对象版本的更新来实现。

使用配置管理工具而降低风险――由于它不干扰软件程序员的工作，所以可以使用常用的工具和文件系统接口。

增加了软件的安全性和保护性 ――通过使用分布式的存储结构，所有的软件资源会随时更新、在硬盘或网络出现错误时那些被ClearCase存储的版本信息会立刻恢复。

减少培训和实现成本 ――ClearCase通过采用透明结构以及和标准开发工具进行集成来实现。

强有力的开发和维护 ――通过和其它工具（如：缺陷追踪）、系统、结构进行集成。

支持不同种类的开发 ――通过兼容不同平台的软件配置管理系统，如：Windows NT、UNIX、和一些Client端的软件，如：Windows 95、Windows NT、Windows 3.1和Windows for Workgroups。

缺点：ClearCase 太贵，易用性差，培训费用很贵，没有培训，很难上手使用。

StarTeam（闭源集中式）

StarTeam属于高端的工具，在易用性，功能和安全性等方面都很不错。 StarTeam的用户界面同VSS的类似，它的所有的操作都可通过图形用户界面来完成，同时，对于习惯使用命令方式的用户，StarTeam也提供命令集进行支持。而且StarTeam的随机文档也非常详细。 StarTeam还提供了流程定制的工具，用户可跟据自己的需求灵活的定制流程。与VSS和CVS不同，VSS和CVS是基于文件系统的配置管理工具，而StarTeam是基于数据库的。StarTeam的用户可根据项目的规模，选取多种数据库系统。StarTeam无需通过物理路径的权限设置，而是通过自己的数据库管理，实现了类似Windowsnt的域用户管理和目录文件ACL控制。StarTeam完全是域独立的。这个优势可以为用户模型提供灵活性，而不会影响到现有的安全设置。StarTeam的访问控制非常灵活并且系统。您可以对工程、视图、文件夹一直向下到每一个小的item设置权限。对于高级别的视图（view），访问控制可以与用户组、用户、项目甚至视图等链接起来。 StarTeam是按license来收费的，比起VSS，CVS来，企业在启动StarTeam进行配置管理需要投入一定资金。

优点：权限设置功能强大方便。StarTeam的图形化界面，能够使初学者易于接收，而且其缺陷控制功能的功能（基于数据库的Change Request），是相应工具中独树一帜的。

缺点：不支持并行开发，不能很好解决Merge的问题；不支持分支的自动合并，需要手动来处理；速度慢，一定程度上影响开发效率；故障恢复困难，需要有专职管理员维护；没有中文版本；另外，StarTeam集成度较高，移植过程复杂，需要的管理负担大，需要完善的备份计划。

GIT（开源分布式）

GIT 是一款免费的、开源的、分布式的版本控制系统。旨在快速高效地处理无论规模大小的任何软件工程。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。每一个GIT克隆都是一个完整的文件库，含有全部历史记录和修订追踪能力。其最大特色就是“分支”及“合并”操作快速、简便。支持离线工作，GIT是整个项目范围的原子提交，而且GIT中的每个工作树都包含一个具有完整项目历史的仓库。

GIT 本来是面向 Linux 操作系统开发的软件。在 Linux 平台上使用GIT非常简单，都是命令行模式。但对windows以及中文的支持不是很好。

Mercurial（开源分布式）

Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目。

相对于传统的版本控制，具有如下优点：

更轻松的管理。传统的版本控制系统使用集中式的repOSItory，一些和repository相关的管理就只能由管理员一个人进行。由于采用了分布式的模型，Mercurial 中就没有这样的困扰，每个用户管理自己的repository，管理员只需协调同步这些repository。

更健壮的系统。分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统通常不会因为一两个节点而受到影响。

对网络的依赖性更低。由于同步可以放在任意时刻进行，Mercurial 甚至可以离线进行管理，只需在有网络连接时同步。

简单易学、易于使用；轻量级，运行快速；可扩展性，易于根据用户需求自行定义、扩展。

Monotone（开源分布式）

Monotone是一个免费的分布式版本管理系统。提供了简单的文件事务版本存储，可离线操作，高效的点对点同步协议，支持历史版本敏感的合并操作、轻量级分支处理以及集成代码评审和第三方测试工具。使用加密的版本命令方式和客户端 RSA 认证，很好的支持国际化，不依赖第三方工具，支持跨平台。 可运行在Linux，Solaris，Mac OSX，Windows和其他Unixes上，遵循GPL协议。

5.SVN和GIT的区别

(1)SVN

SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的。

(2)GIT

git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。[2]  Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

(3) 区别

1.GIT是分布式的，SVN不是：

这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。

GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。

有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。

2.GIT把内容按元数据方式存储，而SVN是按文件：

所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

3.GIT分支和SVN的分支不同：

分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。

然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

4.GIT没有一个全局的版本号，而SVN有：

目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线索，请在评论里奉献出来与大家共享。

更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。

5.GIT的内容完整性要优于SVN：

GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。