现在的位置: 首页 > 综合 > 正文

Visual SourceSafe简明培训教程(中)

2014年02月03日 ⁄ 综合 ⁄ 共 4455字 ⁄ 字号 评论关闭

如需复制、传播,请附上本声明,谢谢。原文出处:http://morningspace.51.net/,moyingzz@etang.com

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)

  VSS提供了3种删除文件的方法:

  • Delete:VSS只把指定文件从当前工程中删除,而在VSS数据库中仍留有该文件的记录。此外,其他共享了该文件的工程仍保留此文件(参见对文件和工程的Branch/Share操作)。
  • Destroy:VSS将把指定文件从VSS数据库中彻底删除,其后将无法恢复。
  • Purge:永久性删除已被Delete掉的文件,其后将无法恢复。

  对于共享文件,Delete和Destroy仅将文件从当前所选工程中删除掉,其他共享了该文件的工程,以及VSS数据库中,仍留有此文件。

4.1.5 移动文件和工程(Move Files and Projects)

  移动一个文件的唯一方法是,在文件新所在位置的上一级工程(parent project)处使该文件共享(参见对文件和工程的Branch/Share操作),然后将原有工程(original project)下的该文件Delete或者Destroy(参见删除和恢复文件、工程)。移动后,文件的历史记录将被保留。

  通过使用Move命令,你可以将一个子工程(subproject)从某个上级工程重置到另一个工程下。该操作不会改变子工程的内容和历史记录,但它会影响上级工程的历史记录(包括子工程所在的原有上级工程和新的上级工程)。当移动一个工程后,你将无法重建原有上级工程的某个旧版本。

4.1.6 重命名文件、工程(Rename Files or Projects)

  若某个文件被多个工程所共享,对该文件的重命名将影响所有工程,而在Branch状态下,则不影响(参见对文件和工程的Branch/Share操作)。

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)

  Get操作将文件或工程拷贝至本地的工作目录,并设置为read-only属性。可以用View操作查看文件内容,此时用户无需设置工作目录。

  尽量不要删除vssver.scc文件。本地工作目录及每个子目录下都包含一个这样的文件,VSS利用其中记录的信息确定本地目录中哪个文件已经更改了。删除后,将使新一次的Get操作速度减慢。

4.2.6 回滚到以前版本(Rollback to Previous Versions)

  该操作将使文件的内容恢复到先前某个版本时的状态,它将使所有在该版本后所做的改动丢失。如果你所回滚的文件被多个工程共享,则操作只影响你所指定的那个工程,并且它会自动实行Branch操作(参见对文件和工程的Branch/Share操作)。建议你使用虚拟回滚(Virtual Rollback),它将不会使随后的改动永久丢失。具体操作如下:

  • 选择你要回滚的文件并签出
  • 使用Get命令获取某个原有版本到本地
  • 签入该文件

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)文件。

  • Multiple Checkout:若多个用户同时签出一个文件,第一个用户只要简单的签入就可以了。后续用户也可以签入,但他们的更改将需要和其他所有用户的更改合并,VSS将得到完整的更改内容(参见多人同时签出一个文件)。
  • Branch:当被Branch的文件合并到其中一个分支时,VSS将会把在另一个分支上所做的改动合并到该分支上(参见对文件和工程的Branch/Share操作)。
  • Merge on Get:在Multiple Checkout工作方式下,当使用Get Latest Version操作时可能引发合并操作,此时保存在VSS数据库中的内容将合并到本地文件。但如果某个文件是排他性签出的,则不会引发合并操作(参见排他性签出)。

  在完成一个合并之后,VSS遵循如下规则:

  • 如果仍有冲突,VSS维持文件的签出状态,为了使文件能顺利签入,你必须排除这些冲突。
  • 如果你使用Merge Branches命令,将一个文件合并到一个工程中,而该工程中的对应文件已被签出,该文件将继续保持签出状态(参见对文件和工程的Branch/Share操作)。
  • 在任何其他时候,VSS将会提示你,或者在合并后自动签入,或者保持文件的签出状态以使你在更新VSS数据库中内容之前再核查一边。

  缺省情况下,当发生冲突时,VSS将启用其Visual Merge工具。

4.2.9 排他性签出(Exclusive Check Out)*

  允许多人同时签出一个文件是针对整个VSS数据库而言的,但用户仍可以根据实际情况,针对某些文件修改该规则。对某个文件实施排他性签出,则其他用户将无法签出该文件,直至该用户使用了签入操作。

4.2.10 对工程的Cloak操作(Cloak Projects)*

  若对某工程实行了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操作。

4.3 Branch、Share、Label和Pin操作(Branch、Share、Label and Pin)

4.3.1 对文件和工程的Branch/Share操作(Branch and Share Files and Projects)*

  在VSS中,通过Share操作,一个文件可以被多个工程共享,在任何一个工程中对该文件的更改,都将反映到其他相关工程里。

  Branch操作则消除这种共享,每次将一个被共享的文件拆成两个分支,在不同工程中分别跟踪该文件。通过查看文件属性的Links属性页可以了解该文件被哪些工程共享,通过查看Paths属性页可以了解文件的分支状况。

  例如:产品目前的正式版本为2.0(工程路径为$/Application),在加入新功能后将升级为3.0。但在开始升级的过程中,其间的一个过渡版本2.1存在bug,需要修改。此时可以进行如下操作:选择被Label标识为2.0的那个版本(参见给文件、工程指定标签),利用Share功能创建过渡版本(工程路径为$/Application2.1),此时两个工程中的文件是共享的,且$/Application2.1中的所有文件都处于Pin状态(参见 Pin操作),即:在向3.0升级的过程中,对$/Application中相关文件的更改,将不影响$/Application2.1下的内容,但此时文件仍是共享的。仅对需要修改bug的文件采取Branch操作。这样做的好处是,中间版本的bug修改工作和3.0的升级工作可以同时进行,并且最大限度的降低了所需的存储空间。

4.3.2 给文件、工程指定标签(Label Files and Projects)*

  VSS使用3种方式跟踪文件的历史记录:内部版本号,日期,用户自定义标签。

  标签可以是一个不超过31个字符长度的串,例如:"1.0"、"2.01b"、"Final Beta"、"Approved for QA"。应用Label功能,用户就可以获取某个特定时期的软件内容了。所有当前工程下的文件和子工程都将继承该标签。

  注意下面几点:

  • 当使用Label功能时,表明你在所选工程的历史记录里创建了一个新的版本,但文件和工程本身的内容并未发生变化。
  • 对某个工程的某个标签再次使用Label操作将覆盖原来的标签内容。

  请参见附录A1:同时维护一个工程的多个版本

4.3.3 Pin操作(Pin)*

  该功能对共享文件很有用,尽管它的使用不仅限于共享文件,也包括其他任何文件。当你对一个文件实施Pin操作后,你将不能对之做任何修改。如果一个文件在Pin之后又被实施了Share操作,而被Pin的那个版本同时也是被共享的版本,则所有共享该文件的工程都不能更改该文件。如果一个文件先被实施了Share操作,而后在某个工程中被Pin了,则除了这个工程外的其余工程仍可以更改该文件(参见对文件和工程的Branch/Share操作)。

(续)

抱歉!评论已关闭.