Thinking in Subversion

Subversion应用前提：

1、只commit测试过的代码

2、人才是最关键的因素，Subversion的成功应用取决于团队中每个成员的依照规则贯彻执行

OK，先介绍下我们的team以前是如何应用Subversion的：

1. 没有使用branch，所有人的工作都在trunk下进行

2. 每个功能的开发周期特别长。i.e. 每次开始编写一个功能，到这个功能能够通过编译/测试，经历一周到数周

3. 每个人负责不同功能的开发，但也存在同时操作同一个文件的可能

4. 为保险起见，每天commit代码到trunk中。所commit的代码可能未通过编译/测试

在这种使用模式下，我们遇到过一些什么问题呢？很多问题！

1. update后代码无法通过编译，到处找人沟通，非常影响心情。

2. 若干天后发现已经修正过的BUG突然又跳出来了，任何修改都被莫名其妙地“回滚”

在使用版本控制工具的时候以上问题应该出现吗？如何正确使用Subversion来避免以上问题？其实，很容易。

在回答具体做法之前先来看看我们组的客观需求：

1. 由于是内核开发，编码周期长。

2. 需要通过频繁commit不完整代码到仓库中，一来比较安全，二来便于回滚某些实验性的工作。

好了，现在看如何在满足客观需求的前提下解决上面遇到的问题：

1. 每个人负责的子系统都各自建立一个branch，例如/xingzhe/branches/linux-xz-fs, /xingzhe/branches/linux-xz-rpc

2. 子系统每完成一个milestone都应该建立一个tag。例如/xingzhe/tags/linux-xz-rpc-tcp-2010-5-14, /xingzhe/tags/linux-xz-rpc-tcp-and-bcl-2010-5-24,分别代表系统完成rpc的开发测试时的代码， 完成后rpc,bcl开发测试时的代码。 不要在tag中修改bug，如果有必要，应该将修改应用到一个新的tag中，例如rpc tcp版本修正一个bug后，可以打一个新tag:/xingzhe/tags/linux-xz-rpc-tcp-BUG62033-2010-7-11，表示修正了62033号bug后，在2010-7-11添加的tag

3. 每实现一个milestone后得到的可编译、可测试代码都应该及时从branch merge到trunk中。尽早merge可以尽早发现需要沟通的地方，避免将来更大规模的麻烦。

【trunk】---checkout---> 【branches】---develop---> 【branches】 ---copy(create tag)---> 【tags】 ---merge---> 【trunk】

4. 任何子系统需要用到其它子系统更新的时候，需要从trunk merge到本地branch中。

如果没有系统学习过Subversion，我是不明白以上流程的内涵的。所以，为了让团队成员理解上述过程，需要对他们进行Subversion用法培训，特别需要了解的概念包括：branch, tag, trunk, version, conflict；特别需要学会用的几个命令包括：copy, merge, switch。培训PPT下载：

最后推荐一本书：《版本控制之道 --- 使用Subversion 2nd》