版本管理的必要性

版本管理器的发展史

Visual SourceSafe 6.0(VSS 6.0)

版本管理的必要性

如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展，那么80～90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现，这就是软件的版本管理。

只要参加过软件开发的人都清楚，现在的软件项目完全由一个人来完成是难以想象而且也是不可能的，通常是有一个研发小组来共同分析、设计、编码和维护，并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中，需要涉及到各个方面的人员，信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间，还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义改动，大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中，由于软件开发所固有的特征，可能会形成众多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何有效地解决这些问题，具体地说就是如下一些问题：

1. 怎样对研发项目进行整体管理；

2. 项目开发小组的成员之间如何以一种有效的机制进行协调；

3. 如何进行对小组成员各自承担的子项目的统一管理；

4. 如何对研发小组各成员所作的修改进行统一汇总；

5. 如何保留修改的轨迹，以便撤销错误的改动；

6. 对在研发过程中形成的软件的各个版本如何进行标识，管理及差异识辨等等。

一个非常直接的反应，我们必须要引进一种管理机制，一个版本管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管理，而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法，诸如在对他人的源程序进行修改时注释修改原因，修改人和日期，如果是多个成员同时进行了修改，那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了，可以说是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了。

其实，版本管理的思想很早就存在于软件开发者的头脑之中，只是以往的认识没有现在人们所意识到的那样迫切。UNIX的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具，现在的Linux更是提供功能强大的能够跨平台的版本管理器，国外公司的基于Windows的版本管理器也已经有了比较成熟的产品，国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中，这里只将对使用比较广泛，有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe 6.0进行详细的介绍，针对普通的研发小组的解决方案，及具体的实现。

版本管理器的发展史

史前时期：

1982年的RCS。现在你可能还能在Unix的发布包中找到它。古典时期：

1990年的CVS（经典的SCM管理器，可惜不能track目录和文件名的改变，今天这个东西已经过时了），1985年的PVCS，1992年的clearcase（价格贵，功能复杂，当然，今天也有很多公司在用），微软的VSS（Welcome to Hell），90年代中期的Perforce(P4，这个工具今天都还在被广泛地使用，尤其是那些中等大小却有着大量开发团队的公司，现在是Google内部最大的代码管理器)。

中世纪时期：

SVN（Linus很不喜欢SVN，2006年引入了Git），AccuRev(强力支持branch和merge，其扮演了一个很重要角色帮助社区脱离clearcase和CVS)。

文艺复兴时期：

BitKeeper——Sun的内部管理工具，Linux的内核代码2002年也用这个工具，其实，很多开源工程都在用这个工具，2005年这个工具的东家BitMover对大家对BitKeeper逆向工程很不满，于是停止支持开源，于是出现了Git。

Git的第一个版本是Linux之父Linus Torvalds亲手操刀设计和实现的（据说只用了一个周末），Linus不仅仅给出一个原始设计（简单的、干净的、天才的），同时，他也用自己那独一无二的风格催生了这个项目。在Linus介绍Git的著名的演讲中，他强烈地批评（好吧，应该算是侮辱）了CVS，SVN，和Perforce：“Subversion是史上最毫无意义的项目，从项目开始就是这样了”，“如果你喜欢CVS，那么你现在应该在某个精神病研究中心或是别的地方”，“别在用Preforce了，它是十分糟糕和可悲的，这绝对绝对是真的”。无论是反对还是喜欢，Linus的确是改变了历史——中世纪已经过去了，现在的世界由分布式系统主宰，以及消除branch和merge的恐惧。Git 基于 DAG 结构 (Directed Acyclic Graph)，其运行起来相当的快。在Git发布后的来年，世界上所有的大型的开源项目全部从Subversion迁移到了Git上，真是很大，这可能是这具星球上最强大最牛最酷的SCM系统了。Git可能并不是最简单的，但它一定会是未来十年的主流。

Mercurial (Hg) 第一次出现在2005年4月，也是因为BitKeeper不免费了。Hg可以和Git在一起使用，但是Hg和Git在设计上不一样，他们对提交/变更的概念是一样的，只不过Git用tree来实现，而Hg则是用扁平的文件和目录来实现（revlog）

Darcs (Darcs Advanced Revision Control System)是另一个让你摆脱Subversion和CVS的工具，2002年开始，今年是2.5版。它的优势是性能，以及他与众不同的历史版本管理——管理patches而不是snapshot（提交/修改），当然，这样一来，历史改变看上去很不好懂。

Bazaar (bzr) 是另一个开源的 DVCS，它试图给SCM的世界里带来一些新的东西。其由Canonical开发（Ubuntu的那个公司），在2008年成为GNU。

Plastic在2006年出现，强力地支持branch和merge，其还提供了强大的图示，包括3D的版本树，Plastic主要是为了让中等开发团队使用，介于大型的团队（ClearCase）和小型的团队（Subversion）之间。

Team Foundation Server (TFS)，微软的新一代SCM工具，主要是为了VSS的失败负责，但是他还不是版本管理上还是很强，只不过，他集成了一大堆各种各样的工具，比如：issue tracking，test management等。

Visual SourceSafe 6.0(VSS 6.0)

VSS 6.0现在是作为Microsoft Visual Studio 6.0这个开发产品家族的一员，如Visual C++ 6.0和Visual J++ 6.0一样。

1. VSS的简单工作原理

Microsoft的VSS 6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的文件进行直接的修改，而是由该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个成员自己的工作目录下进行调试和修改，然后将修改后的项目文件作Checkin提交给VSS，由它进行综合更新。VSS也支持多个项目之间文件的快速高效的共享。当某个成员向VSS中添加文件时，该文件将会被备份到数据库中，以便所有的成员都能共享该文件。而且每个成员对所有的项目文件所作的修改都将被记录到数据库中，从而使得修改的恢复和撤销在任何时刻，任何位置都成为可能。小组的成员可能得到该项目的最新版本，对它进行修改，并保存一个新的版本。

VSS的项目组织管理使得开发小组的协调变得简单容易且很直观，当一个和一组文件发放给另一个成员，小组，Web站点或是任何其他的地址，VSS确保他们之间的真正共享及所选的一组文件的不同版本的安全性。现在，越来越多的开发者可以通过他们的开发环境来访问VSS的功能。而且VSS可以很容易地于Microsoft Access、 Visual Basic、 Visual C++、Visual FoxPro和其他的开发工具集成在一起，一旦VSS集成到开发环境中，就可以象控件一样使用，能够很好地体现出VSS的易用性和强大功能。

2.VSS中的几个重要概念

为了更好的了解VSS，有必要对如下一些概念给予说明。

首先是项目的概念，所谓的项目是一组存在VSS中的文件（任何类型），可以在项目中或是项目之间进行文件的添加、删除、编辑和共享。一个项目与操作系统的文件夹有很多的相似之处，但它更好地支持文件合并、历史和版本控制。所有的文件存在VSS数据库的项目中，开发组成员不能在VSS中的主备份文件上工作（除了检查和版本比对等特殊情况外）而是VSS为每个成员在各自的工作目录下提供一个拷贝以供工作。尽管在没有工作目录的情况下也可以查看某个文件，但如要真正在VSS管理下工作，就必须要创建一个工作目录。　VSS能够维护一个文件的多个版本，包括一个从不同版本之间进行修改的记录。版本控制包括如下方面：

组内协调—在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。当然，VSS管理员可以改变此缺省设置以允许对单个文件同时有多个Checkout，并且仍禁止对他人的修改进行覆盖。

版本跟踪—对老版本的源代码和其他文件进行归档和跟踪，而且这些版本能够被重新得到以便进行bug跟踪或其他目的。

跨平台开发—支持同一代码在跨多个开发平台时的版本控制。

重用或面向对象代码—跟踪哪些程序使用了哪些代码可被重用的模块。

版本控制的涵义在以后的章节中将会得到更进一步的论述。

我们已经知道，VSS 提供版本控制和历史服务，以保证一个文件的每个版本都是可恢复的。VSS用日期/时间戳来记录文件是何时被Checkout或是何时被修改的，它主要有三种方法来跟踪文件和项目的版本：

版本号：这是由VSS维护的内部数码，用户对它没有控制权。每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整数且是递增的。

标签：这些是用户赋给某个项目或文件的某个版本的一个字符串，可以是任何格式的长度不超过31字符的字符串。

日期/时间戳：它给出了一个文件何时最后被修改的信息，或者是一个文件何时被Checkin。VSS同时支持12小时和24小时的时间格式。

工作目录是用户真正对项目文件进行调试修改的地方，当用户Checkout 或提取一个文件时，VSS将该项拷贝到用户的工作目录下，当用户修改了该文件并将其Checkin或提交时，VSS再将它从用户的工作目录拷回到VSS的数据库中。在用户作Checkout时，VSS将会自动管理他的工作目录，诸如创建必要的子目录。而且工作目录可以随时创建或修改。

3. VSS 6.0的一些新增的特征和功能

归档和恢复—在VSS 6.0中这两个操作是在一个用户界面友好的VSS管理员wizard中进行的，而在以前的版本中，它们只能通过命令行来实现。

移动文件—当用户移动文件时，VSS 6.0自动将该文件共享到一个新的项目中，并在原项目中将其删除。在新项目中，该文件的属性是共享的。

多个项目之间的差异比较—该功能允许用户在不同的项目之间进行差异比较。

单个文件的展开—在以前的版本中，VSS只能展开一个目录（文件夹），在VSS 6.0中，同时可以展开一个文件。

快速提取—由于VSS 6.0在性能上的提高，现在的文件提取速度比以往VSS版本的快两倍左右。

历史信息过滤—VSS 6.0 支持查看那些没有标签的文件和项目的历史。

清除临时文件夹选项—该新功能可使用户很方便地清除临时文件夹。

检查外部的超连接—在VSS 的较早的版本中，只有内部的超连接和项目内的跳转才得到检查，VSS 6.0允许用户检查项目之外的超连接和跳转。

创建打开VSS数据库的快捷键—用户可以使用VSS Explorer中该新功能创建一个打开某个特定VSS数据库的桌面快捷键。

HTML格式的帮助—VSS的以往版本使用的是WinHelp格式。