如需复制、传播，请附上本声明，谢谢。原文出处：http://morningspace.51.net/，moyingzz@etang.com
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（参见扩展关键字）
VSS Explore的list view缺省时只显示当前工程中的所有文件。通过使用Search命令，可以只显示符合指定要求的文件。例如：只显示.h文件，只现实被签出的文件。Search命令是允许递归的。
如果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命令也可能操作失败。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版的工作了。
(完)