首先我将讲解VSS中权限机制实现的原理，这里面涉及到VSS的默认安全访问机制、项目安全等内容，接着我将告诉实现权限机制的具体方法，最后我将结合一个软件移交项目的具体情况来谈谈权限管理如何应用到实际的项目过程中。
一、VSS默认的安全访问控制
每次你安装VSS以后，系统自动激活默认的安全访问控制机制。这套机制非常简单，它包括两个等级的权限：
1. 只读权限：用户可以查看VSS数据库中的所有对象，但是不能够修改；
2. 读写权限：用户可以查看和修改VSS数据库中的任何对象。
每次你增加新用户的时候，你可以决定该用户的权限等级。在“Add User”对话框中包含一个“Read Only”复选框，你可以通过它来确定用户具有的权限。
我们前面说过这只是个极其简单、粗线条的解决方案，但同时也是最简单的。在实际过程中，你可能需要更细化的权限分配，甚至希望每个文件针对不同的用户都能设置不同的权限。那我们就得亲自动手设置我们项目的安全机制。
注意：SourceSafe中的所有安全设置都是在Visual SourceSafe Administrator中进行的，所以在深入以下细节之前，你必须确认一件事情：你的Admin密码足够安全，除你之外没有任何人可以随心所欲地进入Visual SourceSafe Administrator。否则，一切安全考虑都是徒劳。
二、项目安全与用户访问权限
在讲解项目安全之前我们先来回顾一下VSS的基本组成框架。VSS包含多个数据库（database），每个数据库又包含许多的项目，而且可能项目里嵌套着不同的子项目，最后才是你的源文件。你可以把这个类比成操作系统中的磁盘分区、目录、子目录、文件，每台机器包含许多的磁盘分区，每个分区中包含无数个目录、子目录，在子目录下才是你的文件。VSS中的用户是基于VSS数据库的，也就是说每个数据库都包含有自己的用户清单。用户访问权限意思是用户可以访问（包括查看、修改和执行命令等）数据库中的哪些项目，对项目来说就是它只能被那些已经授权的用户访问，也就是所谓的项目安全。
很遗憾VSS只提供了到项目（对应于目录）的用户权限控制，并不能针对每个文件来设置不同的用户访问权限（比如Rational ClearCase等就提供此功能）。虽然你可以用某种变通的方法来做到这一点，比如增加子项目，不过那样就破坏了整个项目结构的规范性、可读性和合理性，甚至产生些无任何意义的子项目。
VSS定义了四级用户访问权限，级别由低到高，后者包括所有前者的权限，比如说拥有Check Out权限就自动拥有了读的权限。
1. 只读（R）：允许查看文件，对应于View、Get等命令；
2. Check Out（C）：可以使用Check Out，Check In，Undo Check Out等命令修改文件内容；
3. 文件增删（A）：可以在项目中增加、删除、重命名文件或者给文件加标签，对应的命令有Add，Delete，Label，Rename等；
4. 破坏（D）：这级权限对应于那些具有巨大破坏性的操作（就是那些一不小心就可能被炒鱿鱼的操作），请牢记它们的名字：Destroy，Purge，Rollback。所以亦有人戏称之为自杀权限。
其实你可以发现默认安全机制中的两级权限是和这四者对应起来的，只不过后者把前者的读写权限细分为三个不同的级别。好啦，了解每级权限各自的含义之后我们就可以开始设置不同用户的权限啦。
设置用户权限之前，你必须激活项目安全机制。打开VSS Administrator的Tools菜单，点击“Options”得到SourceSafe Options对话框，选取“Project Security”，并且勾上“Enable project security”复选框。（如下图所示）
图1 激活项目安全机制
VSS中有三种方法可以设置用户的项目访问权限：针对项目设置每个用户的权限，针对用户设置访问每个项目的权限，拷贝用户权限，它们分别对应于Tools菜单下的Assign Rights by Project，Rights Assignments for User，Copy User Rights。我们以方法一为例做一简单说明。如下图所示，在左边框中选定项目，在右上框中选定用户，右下脚的User rights中就显示该用户现具有的权限，选中不同的复选框来设置你自己的权限。注意：对每个项目的用户权限设置自动反映到该项目的所有子项目中。
图2 用户授权
三、权限管理在实际项目中的应用
在本小节中，我主要结合在实际项目过程中作为配置管理员的经验来谈谈权限管理的实际应用，以及在应用过程中需要考虑的因素。
我们要接触的这个项目为一软件移交的项目，这个项目团队的成员组成和职责分配如下：
项目经理：1人，负责协调整个项目。
业务分析师：1人，负责整个系统业务的掌握。
系统架构师：1人，负责整个系统的系统架构。
Package Owner：3人，分别负责系统前端、中间层及后台数据库三个部分。
模块负责人：3-5人，分别负责各个模块。
数据库管理员（DBA）：1人，负责系统数据库。
Test/QA：1人，负责整个软件的测试和质量保证。
Technical Writer：1人，负责相关技术文档的写作。
变更控制委员会（CCB）：3人，负责项目需求的变更审核及执行，包括软件配置管理员，外方项目经理。
实际过程中大多会发生人员交叉现象，比如我们项目的实际人数就只有9人，项目经理又同时是CCB中的一员，Package Owner同时兼任模块负责人。根据我们项目的实际组成情况，我在VSS中给出了如下所示的项目结构：
图3 VSS项目结构
图示说明：
- exec项目中主要存放项目可执行文件或者软件安装文件，由于该项目比较复杂，建立过程耗时长且比较复杂，所以直接在VSS中存放可执行文件。一般的项目不推荐这样使用。
- 图中只是显示整个项目结构的主要部分，省略了细节部分，比如client项目中包含有许多的小项目。
接下来，就需要为每个项目、子项目设置不同的用户访问权限。由于所有的软件重大变更都需要交由CCB审核签字后方可执行，所以我们把整个项目的D（6）级权限赋给CCB成员。而项目经理主要负责项目的整体进度的把握以及与外方项目组、其他部门的协调工作，所以拥有整个项目的R权限并且拥有development document的A权限。配置管理员的权限有两者可能，一种就是拥有整个项目的A权限，另外一种可能就是只拥有部分项目的A权限，这主要取决于赋予给配置管理员的实际权限有多大。以此类推，各个模块负责人拥有各自模块的A权限。此外由于移交项目的特殊性，一般在项目开始过程中主要以培训为主，很少涉及到软件的修改，所以建议在项目开始阶段不赋予开发工程师用户C权限以免引起不必要的错误和争论。
总结
本文通过讨论VSS中权限管理实现的具体机制，并且结合例子讲解了在实际过程中的应用。虽然移交项目有着它本身的特殊性，但我相信对于任何项目来说其安全管理的基本思路是相通的，希望此文能够给大家以一定的启示和借鉴。
使用注意事项，请认真阅读以下内容：（千万记住，否则配合不好影响开发效率）
签出文件：
每次仅签出需要的文件，无关文件不要签出；
公用文件修改时，尽量使用重构功能，保证旧的代码、用法不受修改的影响；
签入文件：
保证签入的文件后，项目可以编译通过
如果文件依赖其他文件中的代码，则相应的文件需要同时签入。
签出修改他人创建文件：
应该先与创建人联系是否可以修改
修改后，应该及时签入文件
每日下班时，请检查以下项目：
是否签出了别人文件。
是否签出了公用代码。
是否有无法编译通过的代码签入了；
相同账号在不同机器登陆，会被认为是不同用户；
必须强行签入文件时，需要使用和签出账号相同的账号；
Guest 帐户为无密码帐户，所以用该帐户登陆，不会提示输入密码，所以尽量不要用该帐户登陆，防止账号错误；
Internet 方式连接也会使用 administrator 帐户自动登陆。
编程时发现代码错误出现在锁定项目时，先获取新版本，在继续编译，如果错误继续存在，则和在页面创建者联系是否嵌入错误；