软件行业有一个关于软件使用的“28”或是什么“37”原则的。也不知道是那位老大总结的，但是真的很准确。我们一直用CVS对代码进行管理，可我想说的是，我一直就使用CVS里最最基本的部分。cvs co,cvs ci, cvs up,cvs add,都是最基本的功能，我从来就没有过仔细的研究一下CVS，惭愧！
我参与的项目release好一段时间了，这期间经历了市场血与火的洗礼...。做应用软件的就是这样，你一定会碰到不同用户的不同需求，你需要为其定制开发。好，当有A省的用户有特殊的需求的时候，我们就用CVS为其建立一个新的project。同理，当有B省用户有特殊的需求的时候，我们还是采用同样的办法。我们一开始没有觉得这样哪里不好，为不同的用户建立不同的project，很清晰，维护起来还挺方便。就像《后天》里的情节哪样，你总是要对你不正确的做法付出惨痛的代价。我们很快发现了我们的做法的致命伤，当我们需要修改一个bug，或者是升级程序，加入通用的功能的时候，我们需要手工同步很多版本。god，大量的重复劳动！我清楚的听到我邻座那个可爱的女孩的抱怨：真麻烦，要同步这么多版本。
有的时候，我觉得自己很幸运^_^。当有一个问题困扰着我的时候，我准备上一个常去的论坛向guru请教的时候，发现大家正在那里热火朝天的讨论着这个问题。这次也差不多，一天晚上和一个以前的同事聊了一些关于版本管理的问题。那个同事现在在一家外企工作，据称他们的版本管理很规范，有很专业的专门人员来做这件事情。他告诉我，应该可以采用CVS的分支功能来解决这个问题。虽然我当时云里雾里，不太明白，他也不是做版本管理的，但是，重要的是这个idea。我是一个听人劝的人，马上从一个同事那里揩来《CVS－开源软件开发技术》那本书。仔细的研究了一下分支的功能。啧啧，这就是我想要的，哈哈，在屋里跳了一会小天鹅。嗯，程序员总是这样大喜大悲的！
把我的轻骑兵音箱调到很大声，听着《痴心绝对》。我喜欢这样写文章^_^。好吧，让我们看看什么是CVS的分支。
我们把一个项目的一个主要开发过程称作开发主线。当某一个特殊事件发生的时候，例如，有一个用户有特殊的需求，于是就从这个开发主线里分离出来一个叉，以满足用户特殊的需求，那么这个叉有它自己的发展方向，这就是分支，就像是一个大树在春暖花开的时候，长出来的新枝。
---------分支
/
/
/
------●----------------------------开发主线
上面这个点，代表开发主线的最新版本，那么这个时候可以从开发主线建立分支来进行定制开发。接下来，开发主线和分支就可以有各种的发展方向。而且，如果可以的话，分支的代码可以重新合并到开发主线中。开发主线的代码也可以更新到分支代码中。
假设在我们的home目录下的proj目录就是我们的工程。下面具体看一下，如何建立分支：
1、先在开发主线上创建一个标签，就是上图中那个点。这样做是为了以后可能有使主干重新回到分支创建时的状态的需求。在你的工程目录的top level下执行cvs tag Root-of-Version_2.5.0.0。
2、创建分支：cvs tag -b ln_version_branch(-b选项就是创建分支)。
3、接下来，你可以在工程目录的top level下直接执行cvs update -r ln_version_branch转到分支上进行工作。也可以通过cvs co -r ln_version_branch -d ln_proj proj命令新checkout一份分支的本地拷贝。-d选项是创建本地目录名字。这里建议用第二种用法，因为在一个本地拷贝下通过命令来回在主线和分支转换，容易产生混淆，你也可能忘记这么去做。
4、这样分支的开发和主线的开发就可以分离开。如果需要的话，可以把分支上的代码合并到开发主线上，当然在合并的过程中可能需要解决一些冲突。cvs update -j ln_version_branch，通过这样的命令把分支代码合并到主线上。当然我们这里的例子是针对用户特殊需求产生的分支，一般不会把分支合并到开发主线中。但是，对于bug修改等产生的分支，就会有需求把分支合并到主线上。这里有一点要强调的是，当开发主线的程序员合并分支的代码的时候，需要互相沟通。在开发主线程序员成功合并分支代码后，在主线代码上要设立一个点(cvs tag)来标志这次合并；在分支代码上开发的程序员，在合并之后，也要建立一个点来标志这次合并，例如，cvs tag ln_version_1。这样做的好处是当下次在进行代码合并的时候，在开发主线上的程序员可以通过命令cvs update -j ln_version_1 -j ln_version_branch，这里ln_version_branch代表分支的末梢，因此该命令不是重新合并整个分支代码，而是合并自从合并点ln_version_1到现在修改的代码，这样可以防止重新合并整个分支而带来的冲突。
5、对于我们这里针对用户特殊需求产生的分支，可能更多需要的是把开发主线上的代码更新到分支上。cvs update -j HEAD,这里HEAD代表了主干的末梢，也就是这个命令合并了主线在创建该分支伊始到目前为止，所有的主线上修改的代码。这里还是需要分支开发人员和主线开发人员沟通。在分支上也需要设立一个点来标志这次合并，这样如果主线需要合并分支代码的时候，可以根据这个点进行新的合并，而不是合并整个分支。主线开发人员也需要设置点来标志这次合并，例如,cvs tage merged-ln_version_1 ,这样下次分支在合并主线代码的时候可以cvs update -j merged-ln_version_1 -j HEAD ,这样防止了分支重复合并主线上的代码，而只是合并最新的修改。
上面我们可以看到，一个主要规则是，当进行代码合并的时候，一定要注意沟通，合理的设置合并点。并且，合并点的名字也应该望文生义^_^。各个线上的合并工作也最好由一个人来做。如果合并点设置不当，那么分支带来的好处可能就会打折扣。并且如果管理的不好，整个项目可能会很乱，产生意大利面条式的分支^_^。
上面，我大概描述了一些CVS中的分支功能，我表达能力有限，可能表达的不是很清楚，还望大家见凉。如果感兴趣，可以详细参考一下各个方面资料。但重要的是idea吗，对吧，我这里仍了一块石子^_^。我想直到今天，我才把CVS这把长剑拔了出来，但只是拔了出来，要想使出独孤九剑，还需要苦练心法才行...。
