CVS tag and branch

转自网络
一、 tag

1.1 revision number（修订号）

要理解tag，首先要介绍一下revision number（修订号）。在CVS中每个文件的版本都有一唯一的 revision number。修订号的形式一般是这样的：'1.1'，'1.2'，'1.3.2.2' 甚至是'1.3.2.2.4.5'。一个修订号总有偶数个用句号分隔的十进制数。按照默认，文件第一个修订号是 1.1。每个新的修订号的最右边的数会比它的上一个修订号的最右边的数大 1。下图显示了一些修订号，较新的版本在右边。
1.1 ----<  1.2 ----<  1.3 ----<  1.4 ----<  1.5
其实，对于大多数 cvs 用户来说，不需要考虑修订号；他们只要知道 cvs 已经自动地加上了类似 1.1，1.2 之类的修订号就可以了。

1.2 tag （标签）

由于每个文件都有自己的修订号，每次提交该文件一次，它的修订号就会就会增加。这样就会产生一个问题：对于软件的某一个发行版，源文件的修订号可能都不一样。例如：

引用

    ci.c            5.21
    co.c            5.9
    ident.c         5.3
    rcs.c           5.12
    rcsbase.h       5.11
    rcsdiff.c       5.10
    rcsedit.c       5.11
    rcsfcmp.c       5.9
    rcsgen.c        5.10
    rcslex.c        5.11
    rcsmap.c        5.2
    rcsutil.c       5.10

因此，要checkout某一个特定的发行版的所有源码的时候，如果是要根据修订号来的话，是异常繁琐和难以跟踪的。这个时候，就要用到CVS提供的很炫的一个功能了：tag（标签）。
标签可以用来标记多个文件的一组修订号。

1.3 什么时候使用tag

tag的功能就像是给你的工程的某个时刻建立了一个快照。添加了tag后，不论你最源文件做了任何修改，只要发现你的修改发生了错误，或者是如果有人宣称在某个版本里有个 bug，但你在当前工作的副本中是找不到那个 bug，都可以根据tag重新rollback回去，或checkout出那个快照。tag给开发人员带了这样的便利，因此在任何重要的开发阶段，都应该打上tag。

在下面的情况都应该考虑给你的工程建立一份快照（tag）：

引用

完成了某个重要的功能
在每一个milestone
在去掉某个存在功能之前
在测试开始之前
在你对源文件做重大修改之前
新建分支的时候
合并分支之前

当然了，这些都是一般性的建议。其实我感觉是只要你觉得做的修改可能会有副作用的时候，就应该打上tag。

二、branches

当多个人合作，可能有这样的情况出现：John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。这时最好的实践方法是使用branches。John建立一个自己的branch，然后在里面实验，必要的时候从Sally的trunk里取得更新，或者将自己的阶段成果汇集到trunk中。

如果项目分为一期、二期、三期等，那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches上，这样二期开发的代码就对一期的代码没有影响，如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码，如果用户使用的过程中发现有bug，则只要在branches上修改该bug，修改完bug后再编译branches上最新的代码发布到生产环境即可。在branches上修改bug的代码要合并到trunk上。