Visual SourceSafe 教程[五]

附录 同时维护一个工程的多个版本(Maintain Multiple Versions of a Project)
　　你可以使用Share/Pin/Branch的方式，也可以使用Label方式。如果你所处的环境只要求少量的改动，比如：轻量级的patch，使用Label比较合适；如果你正在规划大量的开发内容，使用Share/Pin/Branch比较合适。例如：在软件处于Beta版时，你可以通过Label功能冻结（freeze）之，并同时修改Beta版的bug。当你正同时维护着某个产品的1.1版和2.0版时，合理的做法是，为每个版本创建一个新的工程，Share并Pin所有的文件，在需要的时候Branch。当1.1发布时，你可以将1.1版的工程Label，而后将对1.1版的改动重新Merge到2.0版中。下面的几个场景为你使用Label功能提供指导：

场景1：理想情况

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。

场景2：文件A的某个版本被错误地包含在Beta 1版中

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、如果发现文件A某一时期的版本被错误的包含在了Beta 1版中，选择该文件的正确版本并Label为"Beta 1"。
5、获取（Get）Beta 1版的工程。

场景3：需将bug-fix后的文件A被包含在Beta 1版中，而其余文件未曾改动

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、你发现，包含在Beta 1版中文件A的那个版本存在bug，必须改正，而工程中的其余文件则不须改动。
5、签出该文件，改正，然后签入。
6、将工程重新Lable为"Beta 1"（你将被询问是否确认删除原有标记）。

场景4：需将bug-fix后的文件A包含在Beta 1版中，而其余文件也作了改动

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、你发现，包含在Beta 1版中文件A的那个版本存在bug，必须改正，而工程中的其余文件已经改动过且已经被签入。
5、签出该文件，改正，然后签入（此时该文件的VSS内部版本号将自动加1）。
6、将该文件Label为"Beta 1"（和工程的Label同名），这将使该文件的现有版本被指定为"Beta 1"。

场景5：文件A的一个原有版本需要进行bug-fix，并加入Beta 1版中

1、对即将到达Beta 1版的工程进行开发和测试。
2、当你认为时机适宜时，将之Label为"Beta 1"。
3、开始Beta 2版的工作。
4、你发现，包含在Beta 1版中文件A的那个版本存在bug，必须改正。例如：文件的当前内部版本号是6，且包含了为达到Beta 2版所做的某些改动，而你不希望将这些改动并入Beta 1版中。
5、签出文件A（Version 6）
6、获取Version 4，覆盖Version 6的本地版本。
7、修改该文件Beta 1版中的bug，然后签入。这将使文件A的内部版本号升至7（Version 4的内容加上bug-fix后的内容，但没有包含Version 5和Version 6的内容）
8、将Version 7 Label为"Beta 1"。这将使文件A的Version 7版被指定为"Beta 1"。现在，如果你尝试获取Beta 1版的工程时，你将会得到包含bug-fix后的文件A（被单独Label）连同原来Label为"Beta 1"的工程中的其余文件。
9、为了继续Beta 2版的工作，需要恢复在Version 5和Version 6上的改动，再次签出文件A（Version 7）
10、获取Version 6。
11、覆盖Version 7的本地版本，或合并之（这将使本地版本变成Version 6的内容加上你在Version 7中为"Beta 1"所做的bug-fix）。
12、继续修改文件A的本地版本直到你满意，然后签入。这将产生文件A的Version 8，现在你将可以继续Beta 2版的工作了。