Visual SourceSafe简明培训教程(下)

 

如需复制、传播，请附上本声明，谢谢。原文出处：http://morningspace.51.net/，[e-mail]

4.4 其他操作(Other Use)

4.4.1 扩展关键字(Expand Keywords)*

　　VSS可以将某些指定信息（例如：VSS内部版本号）直接插入文本文件中。用户只要将某些关键字放入文件的注释中，每次添加（Add）或签入（Check In）文件时，VSS都会自动查找这些关键字，并将相关信息置于其后。

　　VSS中常用的关键字：

关键字	描述
$Archive: $	文件在VSS中的路径名
$Author: $	最近一次更改文件的用户
$Date: $	最近一次签入的时间
$History: $	文件的历史记录
$Revision: $	VSS内部版本号
$NoKeywords: $	使VSS对其后的所有关键字不进行扩展

　　例如：

　　在某文件中加入如下一行：

　　$Revision: $

　　若当前该文件在VSS内部的版本号是22，则签入后VSS会将之修改为：

　　$Revision: 23 $

4.4.2 使用Shadow目录(Work with Shadow Folders)*

　　Shadow目录位于服务器端，包含了工程中所有的文件。这些文件既非位于VSS数据库中的master copy，亦非位于本地工作目录的local copy，而是最近一次签入的所有内容。Shadow目录应该由管理员来设置。

　　是否使用Shadow目录功能是可选的，通常在如下两种情况下可以考虑使用该功能：

• 为使某些用户能查看文件（但不能更改），这些用户可能没有对VSS的访问权限。
• 不让你的本地工作目录保留可编译的软件副本。为使每个用户都能得到一个最新版本的软件，所有用户可能希望在某个目录下集中进行编译，而非在各自的工作目录下编译。在这种情况下，Shadow目录功能通常和添加（Add）、签入（Check In）之后的Remove Local Copy结合使用。

　　Shadow目录不会跟踪子工程的变化，例如：你有一个被Shadow的工程$/A，包含两个子工程：$/A/1和$/A/2，而你又将$/A/2重命名为$/A/B，这种变化将不会被反映到Shadow目录中。你可以手工修改，或者利用Reconcile All功能，使之保持同步。

4.4.3 性能优化(Optimize Performance)*

　　有两种方法可以改善VSS的性能：尽可能多的将内容通过网络拷贝至本地来做；修改初始化文件对VSS的性能进行微调。

　　具体优化措施：

• 在SS.INI或SRCSAFE.INI文件中设置如下变量：

  Diff_Ignore (PC) = c-e-s-w-

  使VSS在进行文件比较时忽略end-of-line标记，从而加快运行效率

  CP_OnSelection = No

  在使用VSS Explorer时，缺省状态下，用户使用鼠标单击或使用键盘的方向键在工程列表上移动时，就会选中工程。设为No后，只有双击鼠标或按回车键才会选中。

• 设置临时目录

  缺省情况下，VSS将临时文件存于服务器端，但管理员可以通过修改SS.INI中的Temp_Path变量，将临时路径设置在本地。

• 让管理员在SRCSAFE.INI文件中将Lock_Mode变量设置为Native

  这是SRCSAFE.INI中该变量的缺省设置，把该变量设置为Native将使几乎所有的VSS操作都得到加速。该变量只能由管理员来设置。

• 管理员通过Disable下面的功能，也可以一定程度地改善性能：
  • Shadow folders（参见使用Shadow目录）
  • Journal files
  • Project security system（参见安全访问权限）
  • Keyword expansion（参见扩展关键字）

4.4.4 查找文件(Search for Files)

　　VSS Explore的list view缺省时只显示当前工程中的所有文件。通过使用Search命令，可以只显示符合指定要求的文件。例如：只显示.h文件，只现实被签出的文件。Search命令是允许递归的。

4.4.5 设置密码(Set Passwords)

　　如果VSS管理员指定域账号为VSS登录账号，则用户登录VSS时将不会提示输入密码。

4.4.6 编写批处理文件(Writing Batch Files)*

　　在编写批处理文件时，一些在命令行方式下使用的交互手段需要改变。

• 屏蔽输入（Disable Input）

  如果你的批处理文件中包含了一系列VSS命令（它们可能需要整夜运行），你一定不希望程序执行期间会停下来提示用户输入信息。有3个命令行选项可以解决此类问题。

  缺省时，VSS在执行诸如添加（Add）、签入（Check In）等操作时会提示你输入注释（Comment），利用-c选项可以避免该类提示：

  命令	描述
  -c-	不添加注释
  "-cHello"	使用Hello字串作为注释
  [e-mail]	使用comment.txt文件的内容作为注释

  此外，VSS通常会要求用户回答yes或no，你可以使用-i选项避免此类问题：

  命令	描述
  -i-y	对所有此类提问自动回答Yes
  -i-n	对所有此类提问自动回答No
  -i	使用缺省回答

  VSS也可能会提示登录名，你可以使用-y选项提供足够多的信息。

• 重定向输出

  缺省时，VSS将所有输出定向到屏幕，在命令行状态下你可以使用-o选项分页输出，而在批处理文件中你同样可以利用-o屏蔽输出或重定向输出。

  命令	描述
  -o-	屏蔽输出
  -oRESULTS.TXT	重定向所有输出到文本文件results.txt中，如果该文件已存在，输出内容将追加到该文件末尾。

• 使用命令行返回值

  在命令行状态下运行VSS时，VSS会设置一些返回值来标明运行状态。你可以在批处理文件中根据VSS的返回值采取相应措施。

  返回值	描述
  100	表明出错，例如：VSS无法找到数据库文件，或者你试图签出某个早已被签出的文件。
  1	表明一个不是很严重的错误，将在如下三种情况下发生： 当你使用ss Dir时，没有找到任何条目。 当你使用ss Status时，至少有一项被签出。 当你使用ss Diff时，至少有一个文件不一致。 所有这些情况表明，即使本次操作是成功的，你执行的下一个VSS命令也可能操作失败。
  0	VSS成功执行。

4.4.7 定制SS.INI和SRCSAFE.INI文件(Customize the SS.INI and SRCSAFE.INI Files)

　　VSS有两类初始化文件，它们包含了VSS的一些环境变量：SS.INI，每个用户都有一个这样的文件；SRCSAFE.INI，仅有一个，定义了VSS的一些全局变量，只有管理员才有权修改它。

附录  同时维护一个工程的多个版本(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版的工作了。

(完)