如需复制、传播，请附上本声明，谢谢。原文出处：http://morningspace.51.net/，moyingzz@etang.com
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字串作为注释-c@COMMENT.TXT使用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命令也可能操作失败。0VSS成功执行。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版的工作了。(完)
