|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1 说明2 概述3 管理员部分3.1 维护用户列表(Maintain the User List)3.1.1 添加用户(Add a User)3.1.2 更改密码(Change Passwords)3.1.3 创建用户列表(Create a User List)3.1.4 删除用户(Delete a User)3.1.5 编辑用户属性(Edit User Attributes)3.2 管理数据库(Manage the Database)3.2.1 分析数据目录(Analyze the Data Folder)*数据库打包)。VSS数据目录中包含有全部工程和文件的数据库信息。由于网络或操作系统的某些故障,VSS中的文件可能存在错误和不一致问题,Analyze VSS DB工具被用来查找和修复这些问题。在运行该工具前,需要锁定(Lock)所有用户并要求他们退出VSS,用户可以在一个数据库被锁定时保持文件的签出状态(参见锁定数据库)。建议分两次运行Analyze VSS DB工具,第一次修复错误,第二次核查是否仍然存在没有被修复的错误。数据目录的具体位置是由Data_Path初始化变量在SRCSAFE.INI文件中指定的(参见定制SS.INI和SRCSAFE.INI文件)。 一、本教程针对不同使用对象提供Visual SourceSafe 6.0的若干使用指导,阅读对象包括Visual SourceSafe的管理员和普通用户,以及希望了解如何采用Visual SourceSafe进行软件版本控制的管理人员。管理员或普通用户在使用Visual SourceSafe的过程中,如果遇到不知如何操作,或者对某些操作的注意事项不甚了解等类似情况时,可以查阅本教程。 二、本教程的"管理员部分"是管理员必读的,如果管理员在除履行其自身职责之外,还兼任普通用户的角色,则可以参阅教程中的"普通用户部分"。作为一般的普通用户,只需阅读"普通用户部分"即可。 三、教程中列举的操作,加星号者,为高级用法(Advanced Usage),其余为基本用法(Basic Usage)。所谓基本用法是指一些通常使用频繁的,或者是使用方法较为简单的操作。所谓高级用法是指通常使用频率不多,或者较为重要的,或者用法复杂的操作。 四、本教程内容摘选并改编自Visual SourceSafe 6.0英文版联机帮助,从中提取了诸多重要信息、容易忽略的内容以及若干注意事项。一些基本内容(主要指某些基本操作的使用方法)只简单列举了条目,欲了解这些条目的详细情况请查看联机帮助的相关部分,可以通过列于这些条目之后的英文说明在联机帮助中搜索到相关内容。 五、本教程不涉及Visual SourceSafe图形用户界面操作的解释说明,对指定功能的具体操作步骤请查看联机帮助的相关部分。可以通过列于该功能之后的英文说明在联机帮助中搜索到相关内容。 六、在其他Visual Studio产品中(例如:Visual C++)可以集成Visual SourceSafe的功能,本教程不涉及有关在其他集成开发环境下如何使用Visual SourceSafe功能的内容,这部分内容主要针对普通用户。对这些内容的了解,在阅读完本教程之后,将会变得容易。此外,某些操作在Visual SourceSafe环境下使用更为方便。
Visual SourceSafe(以下简称VSS)是一种版本控制管理工具。它通过将各种类型的文件(包括:文本文件、图像文件、二进制文件、声音文件、视频文件等)存入其内部数据库的方式,帮助你有效地管理工程(Project,关于VSS中工程的概念请见下面)。它允许你在多个工程间共享同一组文件;你可以将一个文件添加到数据库中,以便其他相关人员使用;任何对文件的更改将被记录下来,以便在任何时候可以恢复到该文件的某个旧版本。 VSS的工程组织方式使团队协作开发变得更为容易和直观。一个工程是一组存放于VSS数据库内的任意类型的文件,一个工程类似于操作系统中的目录,但VSS为其提供了版本控制、历史记录、文件合并等更多的功能支持。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
建议你定期备份完整的VSS数据目录(参见 3.2.2 数据库打包(Archive Databases)*3.2.3 清除临时目录(Clean Temporary Folder)定制SS.INI和SRCSAFE.INI文件)。 你可能需要定期地备份VSS数据库,或者数据库的某一部分。VSS Administrator工具提供了此项功能。它可以:
VSS通常在运行时把临时结果放在临时目录里,并在退出前将之删除。由于某些原因,例如非正常重启,可能导致临时内容残留在目录中。作为管理员,你有责任定期清除临时目录的内容。每隔几周一次,当没有任何用户运行VSS或VSS Administrator时,请清除临时目录的内容。临时目录的具体位置是由Temp_Path初始化变量在SRCSAFE.INI文件中指定的(参见 3.2.4 锁定数据库(Lock a Database)3.2.5 数据库恢复(Restore Databases)3.2.6 使用多个数据库(Work with Multiple Databases)*对文件和工程的Branch/Share操作)。 数据库锁定功能将不会自动锁定那些当前已经登录的用户,你应该在锁定数据库之前要求登录用户退出VSS。在重新允许用户使用VSS之前,需要解除对数据库的锁定。
此处略,详细内容请查阅联机帮助。
缺省时,VSS将所有文件集中放在一个数据库中。如果可能,应尽量使用一个数据库存放所有文件,这比分多个数据库存放要好,因为:
3.3 有关权限的话题(About Rights)3.3.1 权限的传递(Rights Propagation)安全访问权限),而对于工程"$/Sample",你没有为用户显式指定权限,则该用户将对工程"$/Sample"自动拥有Add权限。当你在工程"$/Sample/BusinessObject"处为其指定了Read权限后,将阻止早先assignment的向下传递过程,所以用户A对该工程(指"$/Sample/BusinessObject")及其子工程都只具有Read权限了。
当你添加了一个新用户,并为该用户设置了针对某个工程的权限时,将在VSS数据库中建立起一个assignment。该assignment将会沿着工程树向下传递直至遇到另一个assignment。 例如:针对工程"$/" ,你为用户A指定了Add权限(参见 当你首次添加一个用户时,该用户在工程"$/"处被赋予的权限由"缺省权限"决定,缺省权限是通过在VSS Administrator里设置Project Security属性页的内容来定义的。你可以通过修改该页内容,全局性地变更所有用户的缺省权限。 3.3.2 安全访问权限(Security Access Rights)3.3.2.1 缺省安全设置3.3.2.2 更高级别的安全控制VSS中部分命令的对应权限级别)
当安装VSS后,缺省安全设置将被启用。你可以利用定制的方式,使某些用户拥有对某些工程和某些VSS命令的特定权限。 缺省安全设置很简单,当添加新用户时,你只有两种级别的访问权限可供选择:
如果这样的访问权限级别足以应对日常使用,那么就无需再增强安全控制的级别了。 所有的VSS安全管理都在VSS Administrator中进行。任何能运行该程序的用户都可以改变VSS的任意特性,所以最好只有管理员才使用该程序。
在VSS中,对工程的安全性控制,是通过制定用户访问权限来实现的。每个工程仅能被那些具有相应权限的用户访问到,每个命令仅能被那些具有相应权限的用户使用。可以通过VSS Administrator来定制权限,以达到更高级别的安全控制。 以下是VSS的权限级别列表,下列每种权限都拥有该权限之前的全部权限。例如:拥有Check Out权限的用户,也将同时拥有Read权限。(参见附录A2:
4 普通用户部分4.1 对工程、文件的一般性使用(Normal Use about Projects and Files)4.1.1 打开/关闭数据库(Open/Close a Database)4.1.2 创建新工程(Create New Projects)4.1.3 添加文件、目录、工程(Add Files,Folders,and Projects)4.1.4 删除和恢复文件、工程(Delete and Recover Files and Projects)对文件和工程的Branch/Share操作)。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
VSS提供了3种删除文件的方法:
对于共享文件,Delete和Destroy仅将文件从当前所选工程中删除掉,其他共享了该文件的工程,以及VSS数据库中,仍留有此文件。 4.1.5 移动文件和工程(Move Files and Projects)对文件和工程的Branch/Share操作),然后将原有工程(original project)下的该文件Delete或者Destroy(参见删除和恢复文件、工程)。移动后,文件的历史记录将被保留。 移动一个文件的唯一方法是,在文件新所在位置的上一级工程(parent project)处使该文件共享(参见 通过使用Move命令,你可以将一个子工程(subproject)从某个上级工程重置到另一个工程下。该操作不会改变子工程的内容和历史记录,但它会影响上级工程的历史记录(包括子工程所在的原有上级工程和新的上级工程)。当移动一个工程后,你将无法重建原有上级工程的某个旧版本。 4.1.6 重命名文件、工程(Rename Files or Projects)对文件和工程的Branch/Share操作)。 若某个文件被多个工程所共享,对该文件的重命名将影响所有工程,而在Branch状态下,则不影响(参见 4.1.7 设置工作目录(Set Working Folders)4.2 签入、签出、获取、查看及相关操作(Check In/Out、Get、View and Other Related Use)4.2.1 签入签出操作(Check In and Check Out Files)4.2.2 撤销签出(Undo Check Out)4.2.3 获取最近版本(Get Latest Version)4.2.4 获取早期版本(Get Earlier Version)4.2.5 获取和查看文件、工程(Get and View Files and Projects)4.2.6 回滚到以前版本(Rollback to Previous Versions)对文件和工程的Branch/Share操作)。建议你使用虚拟回滚(Virtual Rollback),它将不会使随后的改动永久丢失。具体操作如下: 此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
执行该操作时,若用户选择了替换本地文件,则用户将丢失最近一次签出后对该文件在本地的更改。
此处略,详细内容请查阅联机帮助。
此处略,详细内容请查阅联机帮助。
Get操作将文件或工程拷贝至本地的工作目录,并设置为read-only属性。可以用View操作查看文件内容,此时用户无需设置工作目录。 尽量不要删除vssver.scc文件。本地工作目录及每个子目录下都包含一个这样的文件,VSS利用其中记录的信息确定本地目录中哪个文件已经更改了。删除后,将使新一次的Get操作速度减慢。
该操作将使文件的内容恢复到先前某个版本时的状态,它将使所有在该版本后所做的改动丢失。如果你所回滚的文件被多个工程共享,则操作只影响你所指定的那个工程,并且它会自动实行Branch操作(参见
4.2.7 多人同时签出一个文件(Check Out Multiple Files)*合并) 缺省状态下,一个文件只允许一个人签出,管理员可以通过修改配置,允许多人同时签出。此时,VSS将跟踪所有签出该文件的用户。每当用户签入时,VSS都将和当前存于数据库内的最新版本进行比较,若用户修改的是同一文件的不同处,VSS将进行简单的合并(Merge),否则提示用户,并且不允许签入。用户可以通过VSS提供的Visual Merge工具,比较存放于VSS数据库中的文件和本地文件的异同,手工修改本地文件,直到认为已经可以签入时,方才执行最终签入操作。(参见 4.2.8 合并(Merge)*多人同时签出一个文件)。 在VSS中,合并可能发生在3种场合下:使用Multiple Checkout的工作方式;合并原先已经Branch了的文件;获取(Get)文件。
在完成一个合并之后,VSS遵循如下规则:
缺省情况下,当发生冲突时,VSS将启用其Visual Merge工具。 4.2.9 排他性签出(Exclusive Check Out)*4.2.10 对工程的Cloak操作(Cloak Projects)*4.3 Branch、Share、Label和Pin操作(Branch、Share、Label and Pin)4.3.1 对文件和工程的Branch/Share操作(Branch and Share Files and Projects)*给文件、工程指定标签),利用Share功能创建过渡版本(工程路径为$/Application2.1),此时两个工程中的文件是共享的,且$/Application2.1中的所有文件都处于Pin状态(参见 Pin操作),即:在向3.0升级的过程中,对$/Application中相关文件的更改,将不影响$/Application2.1下的内容,但此时文件仍是共享的。仅对需要修改bug的文件采取Branch操作。这样做的好处是,中间版本的bug修改工作和3.0的升级工作可以同时进行,并且最大限度的降低了所需的存储空间。 允许多人同时签出一个文件是针对整个VSS数据库而言的,但用户仍可以根据实际情况,针对某些文件修改该规则。对某个文件实施排他性签出,则其他用户将无法签出该文件,直至该用户使用了签入操作。
若对某工程实行了Cloak操作,则当对该工程的上一级工程进行Get/Check In/Check Out/Undo Check Out/Project Difference操作时,将不会影响该工程及其子工程。而在该工程上进行类似操作时,则和平常得到的结果一样。这一属性将传递给其下的子工程。 例如:某个工程其路径为$/Application,下面有三个子工程:$/Application/Code,$/Application/Test,$/Application/Docs,而Docs工程下的内容可能对你没有任何用处。当你每次从$/Application处进行Get操作后,都需要从本地删除多余的Docs目录。此时可以对Docs进行Cloak操作。这样,每次的Get操作将只把Code和Test下的内容放到本地。如果你需要获取Docs工程下的内容,则可以单独从Docs处进行Get操作。
在VSS中,通过Share操作,一个文件可以被多个工程共享,在任何一个工程中对该文件的更改,都将反映到其他相关工程里。 Branch操作则消除这种共享,每次将一个被共享的文件拆成两个分支,在不同工程中分别跟踪该文件。通过查看文件属性的Links属性页可以了解该文件被哪些工程共享,通过查看Paths属性页可以了解文件的分支状况。 例如:产品目前的正式版本为2.0(工程路径为$/Application),在加入新功能后将升级为3.0。但在开始升级的过程中,其间的一个过渡版本2.1存在bug,需要修改。此时可以进行如下操作:选择被Label标识为2.0的那个版本(参见 4.3.2 给文件、工程指定标签(Label Files and Projects)*同时维护一个工程的多个版本 VSS使用3种方式跟踪文件的历史记录:内部版本号,日期,用户自定义标签。 标签可以是一个不超过31个字符长度的串,例如:"1.0"、"2.01b"、"Final Beta"、"Approved for QA"。应用Label功能,用户就可以获取某个特定时期的软件内容了。所有当前工程下的文件和子工程都将继承该标签。 注意下面几点:
请参见附录A1: 4.3.3 Pin操作(Pin)*对文件和工程的Branch/Share操作)。 该功能对共享文件很有用,尽管它的使用不仅限于共享文件,也包括其他任何文件。当你对一个文件实施Pin操作后,你将不能对之做任何修改。如果一个文件在Pin之后又被实施了Share操作,而被Pin的那个版本同时也是被共享的版本,则所有共享该文件的工程都不能更改该文件。如果一个文件先被实施了Share操作,而后在某个工程中被Pin了,则除了这个工程外的其余工程仍可以更改该文件(参见 4.4 其他操作(Other Use)4.4.1 扩展关键字(Expand Keywords)*4.4.2 使用Shadow目录(Work with Shadow Folders)*4.4.3 性能优化(Optimize Performance)*使用Shadow目录)
VSS可以将某些指定信息(例如:VSS内部版本号)直接插入文本文件中。用户只要将某些关键字放入文件的注释中,每次添加(Add)或签入(Check In)文件时,VSS都会自动查找这些关键字,并将相关信息置于其后。 VSS中常用的关键字:
例如: 在某文件中加入如下一行: $Revision: $ 若当前该文件在VSS内部的版本号是22,则签入后VSS会将之修改为: $Revision: 23 $
Shadow目录位于服务器端,包含了工程中所有的文件。这些文件既非位于VSS数据库中的master copy,亦非位于本地工作目录的local copy,而是最近一次签入的所有内容。Shadow目录应该由管理员来设置。 是否使用Shadow目录功能是可选的,通常在如下两种情况下可以考虑使用该功能:
Shadow目录不会跟踪子工程的变化,例如:你有一个被Shadow的工程$/A,包含两个子工程:$/A/1和$/A/2,而你又将$/A/2重命名为$/A/B,这种变化将不会被反映到Shadow目录中。你可以手工修改,或者利用Reconcile All功能,使之保持同步。
有两种方法可以改善VSS的性能:尽可能多的将内容通过网络拷贝至本地来做;修改初始化文件对VSS的性能进行微调。 具体优化措施:
4.4.4 查找文件(Search for Files)4.4.5 设置密码(Set Passwords)4.4.6 编写批处理文件(Writing Batch Files)*4.4.7 定制SS.INI和SRCSAFE.INI文件(Customize the SS.INI and SRCSAFE.INI Files)附录A1 同时维护一个工程的多个版本(Maintain Multiple Versions of a Project)A2 VSS中部分命令的对应权限级别 VSS Explore的list view缺省时只显示当前工程中的所有文件。通过使用Search命令,可以只显示符合指定要求的文件。例如:只显示.h文件,只现实被签出的文件。Search命令是允许递归的。
如果VSS管理员指定域账号为VSS登录账号,则用户登录VSS时将不会提示输入密码。
在编写批处理文件时,一些在命令行方式下使用的交互手段需要改变。
VSS有两类初始化文件,它们包含了VSS的一些环境变量:SS.INI,每个用户都有一个这样的文件;SRCSAFE.INI,仅有一个,定义了VSS的一些全局变量,只有管理员才有权修改它。
你可以使用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:文件A的某个版本被错误地包含在Beta 1版中 1、对即将到达Beta 1版的工程进行开发和测试。 场景3:需将bug-fix后的文件A被包含在Beta 1版中,而其余文件未曾改动 1、对即将到达Beta 1版的工程进行开发和测试。 场景4:需将bug-fix后的文件A包含在Beta 1版中,而其余文件也作了改动 1、对即将到达Beta 1版的工程进行开发和测试。 场景5:文件A的一个原有版本需要进行bug-fix,并加入Beta 1版中 1、对即将到达Beta 1版的工程进行开发和测试。
下表中打星号表示具有该类权限的用户可以使用该命令。
[1] 此处指用户必须有对Parent Project的A类权限。 |