学习一下VSS【一篇老笔记】

作为随笔的一个呼应，重新贴一下：

1，admin——Tools——Rights：权限控制及默认权限控制；

2，三种删除：Delete：VSS只把指定文件从当前工程中删除，而在VSS数据库中仍留有该文件的记录。此外，其他共享了该文件的工程仍保留此                          文件。
             Destroy：VSS将把指定文件从VSS数据库中彻底删除，其后将无法恢复。——Delete操作时的一个选项。
             Purge：永久性删除已被Delete掉的文件，其后将无法恢复。——Delete时没有Destroy并且后来想彻底删除时使用：选择已Delete文件原来所在的project——右键Properties——Delete Items（跟垃圾箱一个模式）——有两个选项：Purge（彻底删除），Recover（还原）：如果该文件被checkout过，则Recover时将自动进行一次checkout，然后还原至VSS数据库。

3，Label：我觉得就是标识版本所用，会在History中单独表示出来，如果想要在两个版本中间插入自己的说明并显示在history中，则用lable；当使用Label功能时，表明你在所选工程的历史记录里创建了一个新的版本（只是一个虚拟的版本），但文件和工程本身的内容并未发生变化。
          Label的时候要区分：对project的Label和对文件的Label；
                             对project的Label将反映在该project的History中和所有文件的History中；
          VSS使用3种方式跟踪文件的历史记录：内部版本号，日期，用户自定义标签。——对应于History中的各个字段。

4，Get Latest Version：菜单栏上有这个工具；

5，Get Earlier Version：版本控制：Tools——ShowHistory——ok：记录了所有的版本信息：可以进行：
                        Get操作：获取任意一个版本的source；
                        Diff操作：选择一个以前的版本，则可以比较当前最新版本之间的不同，用彩色标识；但好像只能比较二进制文件
                        Pin操作：一个文件被pin后将不能修改，（1）对Label所产生的虚拟版本进行pin操作，会pin住它的“实在”版本；（2）pin与share交融有奇效：先pin后share——两个project中的文件都被pin；先share后pin——两个project的pin属性不同；
                        Rollback操作：回滚到以前的某个版本，此版本之后的History信息和所有改动全部丢失，但好像只是本地project的信息丢失，其他共享该project的项目中的改版本信息并不丢失，待考察？（1）checkout状态的文档不能被rollback；（2）rollback后，你的本地workingFolder中的文档将回滚至老版本，而不能理解为：服务器回滚，本地未回滚，本地再次checkout才使本地回滚生效。（3）对Label产生的虚拟版本和它的“实在”版本之间没有rollback操作。
                        Share操作：<见后——Share/Branch>

6，还有一种手工回滚的方法：选择你要回滚的文件并签出 ；
                           使用Get命令获取某个原有版本到本地——这样History和该老版本之后的版本信息都不会丢失；
                           签入该文件 ；
   我想这应该是一般用户希望的效果，其实这不光是回滚的意思了，回滚后还可以返回到新版本，
   所以：可以说这个办法是user希望得到任何一个新/老版本的好方法。

7，多人同时签出一个文件(Check Out Multiple Files)：
   VSSadmin——Tools——Option——General：Allow Multiple Checkout
   多人checkout后，文档上会有多个红色的小勾，呵呵。
   VSS将跟踪所有签出该文件的用户。每当用户签入时，VSS都将和当前存于数据库内的最新版本进行比较，若用户修改的是同一文件的不同处，VSS将进行简单的合并（Merge），否则提示用户，并且不允许签入。弹出Merge对话框，让我们手工修改冲突（修改的是本地文件，上面出现的两个窗口：vss和本地的两个不同版本只是给我们一个修改的基础）的地方，直到满意为止（其实一点也不修改，就点保存，照样没问题，意思就是以我现在的为准）——保存——关闭——然后就弹出“是否checkin”的对话框，此时就可以checkin了，如果此时不checkin，则在下次对该文档checkin的时候不再出现Merge对话框，而只有一个简单的warnning：问你是否已经解决了所有冲突，Yes则checkin。
   此时所有文件都可以进行多人签出，如果想个别关掉某个文件的此属性，可在checkout时候的advantage选项中关闭。

8，Cloak：对某个project（文件夹）进行Cloak操作（右键属性——General中），尤其对多个subProject（即子文件夹）中的某个进行Cloak操作，可以在checkout父project的时候，不checkout被Cloak的subProject。
   作用：如果你对某个工程中的一个小项目不感兴趣，并且checkout的时候不想要它，则Cloak它。

9，Share/Branch:
   在Project上右键——share操作：可以共享其他project的文件，并且版本是同一的，在任何一个工程中对该文件的更改，都将反映到其他相关工程里。
   在Project上右键——Show History——Share操作：把自己共享给别的porject（和上面的模式相反），也可以理解为产生一个自己的“副本”，并且该“副本”中所有文件都被Pin住了——我猜可能是想尽量减少误操作吧，毕竟share一个project比share一个file要危险的多，万一多某个文件被误操作则不易辨别出，而pin住后，你想操作一个file就必须先unpin它，至少可以引起你的注意，记住这个文件我要修改。
   文件的属性中links标签可以看出当前所有共享该文件的project；
   Branch：——菜单栏上有Branch工具（一个断开的链子，意指：断开link）
   Branch操作消除Share属性，每次将一个被共享的文件拆成两个分支，在不同工程中分别跟踪该文件。（我不太了解VSS内部是怎样分配Share/Branch的file的，是分配共同的数据块还是用SeperateDataSect，要么是自动增加容量的只记录差异的DataSect。）
   文件的属性中Path标签可以看出当前该文件处于哪几个project的Branch中；
   联机帮助中有一个例子：Application2.0——2.1——3.0的版本控制中如何联合发挥 ：Share-Pin-Branch 的作用。

10，扩展关键字(Expand Keywords)：
    （1）VSS administrator里面要先允许Expand Keywords功能：Tools——Option：FileTypes标签中要加上想要操作的文件的格式（如把*.txt加到binary files中），然后General标签中Expand Keywords in files of type 中要加上想要操作的文件格式（如*.txt）；
    （2）VSS中常用的关键字：   关键字 描述
           $Archive: $         文件在VSS中的路径名
           $Author: $          最近一次更改文件的用户
           $Date: $            最近一次签入的时间
           $Modtime: $         最近一次修改的时间
           $History: $         文件的历史记录
           $Revision: $        VSS内部版本号
           $NoKeywords: $      使VSS对其后的所有关键字不进行扩展
           $Header: $          Logfile, Revision, Date, Author
           $JustDate: $        Date, without the time addendum.
    （3）在自己的文件（如*.txt）文件中任意位置加入这些关键字，则会在每次checkin和add操作时触发响应功能——一旦checkin后，本地文件的相关更改已经完成，不需要再次checkout观察关键字的生效情况。

11，Shadow：管理端设置，Tools——Option——ShadoeFolder：一次只是copy某个project的最新副本，并且该副本基本上与原来的project无关，不同步，不跟踪，可以理解为一个孤立静态的副本。
            可以给领导看哦！

12，一般步骤：开发一个版本，Label为App1.0；
              继续开发App2.0版本；
              发现1.0中某文件有bug，checkout该文件的历史版本；
              修改，checkin；
              Label该文件为App1.0，则App1.0版本将包含新的该文件；此时，如果你尝试获取App1.0版的工程时，你将会得到包含bug-fix后的文件（被单独Label）连同原来Label为"App1.0"的工程中的其余文件。

   如果欲开发新版本的Application并且新旧版本差别较大，需要隔离且不考虑磁盘空间的浪费，可以把当前的Application作一次Share＋Branch，并命名为 ： Application＋版本号；