前言

　　如今随着软件项目规模的日益增大以及项目复杂性的不断加剧，软件配置管理（SCM）的重要性已越来越受到大家的认可。许多优秀的软件配置管理工具也应运而生，使得我们能够轻松有效地管理我们的软件项目，作为这其中的一员，Microsoft Visual SourceSafe具有简单易用、方便高效、与Windows操作系统及微软开发工具高度集成等优点。
我相信有相当一部分人曾经使用或者正在使用VSS，对于它的一些基本用法在这里不再赘述，本文将主要探讨Visual SourceSafe 6.0中的一些高级特性，希望给大家在实际的工作过程中带来一些帮助。

　　我们知道随着软件规模的日益增大，软件开发周期会变得越来越长，投入的人力也会越来越多。在整个过程中，将不可避免地会产生并行开发的情况，那么在VSS中是如何支持并行开发的呢？在并行开发的过程中要注意些什么呢？这就是本文希望与大家分享的。

　　本文要求读者对VSS有一定的熟练程度。

一些有用的设置

　　在讲解并行开发之前，让我们先来看看VSS中一些非常有用的系统设置，他们可以用来加强管理或者简化你的工作。首先是一些与你的项目安全管理策略有关的设置，比如"是否允许multiple checkouts"、"是否激活项目安全机制(project security)"等。还有一些是方便工作的，比"设置影子目录(shadow folders)"、"重用上次注释"、"双击直接编辑文件"、"是否采用图形化归并"等。这些你都可以在"Tools"-〉"Options"里进行设置。

什么情况下会出现并行开发

　　不知道有没有喜欢听评书的朋友？我想一定和我一样最讨厌听到：欲知详情如何，且听下回分解。不过我们今天要讲的是另外一句话：花开两朵，各表一枝。我记得当时虽然这边打得热火朝天，大呼过瘾，但是心里总是惦记着那边怎么样啦！真恨不得有两个电台，一边是鲁智深大闹野猪林，一边是林教头风雪山神庙。那么在实际的项目开发过程中，什么时候会出现花开两朵的情况呢？

　　1、 你想修改项目早期版本中的某个bug。

　　2、 其它的小组成员占有了你希望处理的文件。你可以等他将该文件check in，或者你可以采取multiple checkouts，你还可以选择在一个分支上工作。

　　3、 你所做的工作涉及到许多文件，你选择一个分支流就可以避免经常打乱别人的工作。同时你可以将所有的工作测试完后再将它们集成到你的项目中。

　　4、 项目规定你不能够在主线上工作。相反地，项目被分成许多小的部件，每个部件是一个分支，只有该部件完成后，才会将它合并到主线中。

　　那我们是不是需要两个电台呢（建立两个项目）？可喜的是，VSS中提供了共享、分支等操作来解决并行开发的问题。

文件共享(share files)的概念

　　在VSS中你可以在不同的项目之间共享文件。我们知道，在VSS的数据库中有且仅有文件的唯一拷贝--主控拷贝(master copy)，因此共享文件也就是在不同的项目里建立了指向该主控拷贝的链接。如果你在其中一个项目中改变此文件，那么其他项目中所有的共享也随之改变。此外，如果选择共享某个项目中的所有文件，我们也可以称之为共享该项目。

如何实现文件共享

　　1、 在VSS Explorer中，选择你希望在其中共享文件的项目。

　　2、 选择SourceSafe菜单，单击Share，或者单击右键菜单中的Share显示Share对话框。

　　3、 通过选择Project和File to Share下拉框来选择你准备共享的文件。

　　4、 点击Share.

　　5、 点击Close.

　　如果你选择的是某个项目，系统还会提示你输入新的共享项目名称。操作完成后，你会发现在当前项目中增加了刚才选择的文件。如附图一所示，我在项目$/projectname/sourcecode/client中共享了项目bugfix，操作完成后在client下增加了目录bugfix，而且我将$/bugfix项目中的network.txt文件check out出来后，项目$/projectname/sourcecode/client/bugfix中的network.txt文件也自动被check out。（见附图二）

附图一：文件共享

附图二：文件共享后

　　文件共享机制确实为我们带来了不少便利之处，它可以减少数据库中文件的数量，能够实现文件的重用。但是，文件共享机制的"非各自独立性"也限制了它扮演更重要的角色，真所谓"成也萧何，败也萧何"！

分支操作(branching)

　　要真正地支持并行开发，就不得不用到分支操作。与共享操作不同的是，分支操作实际上是将文件放在不同的项目中来实现完全的独立性，此时在一个项目中的文件修改不会影响到其他的项目中的文件。此外，共享操作后形成的位于不同项目里的两个文件拥有一个共同的祖先，也就是他们的历史(history)记录是从同一点分离出来的。

如何实现分支操作

　　注意，在进行分支操作前，你必须确认已经共享了该文件。当然，你也可以将共享、分支操作放在一起完成。

　　1、 在VSS Explorer中选择目标文件。

　　2、 选择SourceSafe菜单，单击Branch显示Branch对话框。

　　3、 如果需要，你可以在Comment框中加入注释。

　　4、 单击OK。

附图三：分支操作

　　操作完成后，你将会发现项目$/projectname/sourcecode/client/bugfix中的文件network.txt由check out状态变成了uncheck out状态，而且改变项目$/bugfix中的network.txt文件对它也没有任何影响。

如何在具体的应用中使用这些特性

　　那些书上的大侠们学好本领后，都要到江湖上去闯荡一番。那我们了解这些基本的操作后，也一定希望能够在实际的项目中小试牛刀，我们就以早期版本中的bug修改为例。

　　我们假定我们项目的2.0版本刚刚完成，项目开发小组继续朝着3.0版本前进，同时试用项目维护人员需要一个临时的2.1版本来修改试用过程中发现的bugs。具体的步骤如下：

　　1、 将当前项目$/projectname/sourcecode/client加上标签(Label)--Version 2.0。

　　2、 继续在该项目上进行修改，形成新的版本。（如附图四）

　　3、 这个时候在版本2.0的试用过程中发现错误，你需要一个临时的版本来修改错误同时又不影响版本3.0的开发。

　　4、 选择Tools菜单，单击Show History显示Project History Options对话框。

　　5、 选中Include Labels复选框。

　　6、 单击OK显示History of Project对话框。

　　7、 选择加有标签"Version 2.0"的版本。

　　8、 单击Share显示Share From对话框。

　　9、 选择将要产生的项目的父项目，我们选择$/。

　　10、单击OK显示Share对话框。

　　11、将此项目命名为bugfixAfterV2.0，单击Close退出History of Project对话框。

　　12、操作完成后会发现在VSS中增加了一个项目$/bugfixAfterV2.0（注意此时文件2.txt前面的图标形状，如附图五），试着check out文件2.txt，系统会提示你所有的文件已被"钉住"(pinned)，操作不成功。是的，你还需要下一步操作。

　　13、选定那些你确实需要修改的文件，然后进行分支操作。这样你就可以任意修改这些文件，而且你会发现图标也恢复到原来的样子。

附图四：分支操作前的项目历史记录

附图五：分支操作完成后

文件归并(merge files)

　　正所谓，分久必合，合久必分。分支操作以后，你肯定需要重新将这些文件合并到一起，比如上面那个例子，你肯定希望在版本2.0中被修改了的错误不要在版本3.0中再出现，这个时候你就需要用到归并操作。

　　所谓文件归并就是将由一个文件产生的多个不同拷贝重新形成一个唯一的新的文件版本，一般都是将分支上的改变反映到主线上，所以称之为归并操作（当然还存在其他两种情况，使用multiple checkouts，某些情况下get一个文件的时候）。在文件归并过程中VSS并不能去决定文件差异的取舍，它只是将这些文件间的异同提交给你，由你自己来确定最后的文件内容。当然比较的基准就是我们前面提到的它们共同的祖先。

　　有两种方法可以进行归并操作，一种是默认的visual merge，另一种是manual merge。一般推荐使用前一种方法。

　　文件归并过程中涉及到两个概念，一个是投送者(contributor)，另一个是目标(object)。投送者就是你在分支上的那些文件，目标就是你在主线上的那些文件，归并操作完成后，只有目标的内容改变，而投送者的内容保持不变。

如何实现归并操作

　　1、 在VSS Explorer中选择目标文件或者项目。

　　2、 选择SourceSafe菜单，单击Merge Branches显示Merge To对话框。

　　3、 在Projects框中选择投送者所在的项目名称，所以说该对话框的名称应该为Merge From，而不是Merge To。

　　4、 单击Merge显示Comment对话框。

　　5、 输入注释，点击OK。

　　6、 如果两者之间的差异很明显（比如一个文件比另外一个文件多出一行），系统会自动帮你决定目标文件的内容。反之，系统显示Visual Merge对话框，你可以自己决定目标文件的内容。（3）

　　操作完成后，查看一下目标文件是不是变成了你希望的内容。

　　好啦，至此所有的工作已经完成。你可以放松一下来杯浓茶，不敢喝咖啡，怕被Sun公司控告侵权。但是中国人有个习惯，不管什么东西都喜欢分出个高低，排个名次。我记得小的时候对隋唐演义中的好汉排名津津乐道，什么第一名李元霸，第二名宇文成都等等。那好，我们也来啰嗦一下，评评VSS的功过是非。（4）

评说VSS

　　在支持并行开发方面，VSS提供了大量优秀简洁的特性，但是在以下几个方面稍显不足：

　　1、 在进行分支操作的时候，灵活性不是很大，只能是单一地选择某个项目中的所有文件，不能进行一些自定义的设定，比如我只希望选取所有的文本文件。

　　2、 由于VSS中主线和分支是采用不同的项目来区分，所以很容易被混淆而且增加项目的数量，不如采取版本号来区分直观。

　　3、 在进行归并操作时，投送者与目标的概念很模糊，而且没有显示地提出这两个概念。

　　4、 由于VSS中没有版本树的概念，所以分支操作后没有一个直观形象的版本演化的感官认识，就像Rational ClearCase中那样，这样使得不能把分支和主线很好地联系在一起。

总结

　　本文主要讲解一些VSS使用中的高级特性，使得你能够用来应付一些比较复杂的情况。但是，VSS毕竟只是一种工具，项目配置管理的成败主要取决于项目的配置管理策略。

说明

　　1) 本文所有的例子都是基于Visual SourceSafe 6.0英文版，其他的版本可相应对照。

　　2) 这两个概念是从Rational ClearCase借用过来的。

　　3) 关于Visual Merge对话框的详细信息，可以参考VSS的帮助文档。

　　4) 当然本文不准备在整体上来评价VSS，主要是从支持并行开发这个方面来说说VSS的不足之处，只要与Rational ClearCase进行对照。

作者简介

　　王和全，毕业于南昌大学。现主要在J2EE平台上从事广电行业运营系统的开发工作，擅长组件技术，多层架构下的编程。喜欢钻研新的技术，最近又迷上了Linux。除了写程序，平生最大的爱好就是旅游，梦想有一天能开着自己的宝马去郊游。您可以通过wanghequan@shdv.com与我联系，我期待着朋友们的来信。