SVN配置管理实践--代码管理

 

以下是本人用SVN管理代码的一些实践，但并不一定是“最佳实践”，条条道路通罗马，适合你自己的，才是最好的，仅供参考

 

1.SVN Layout:

---/branch/

---/trunk/

---/tags

------/release

------/20100101

------/20100201

------/20100301

------/20100401

------/release 1.0

.

.

.

------/release 2.0

.

.

.

 

2.下面分阶段，介绍每个分支的作用

(a)开发初始阶段

开发初始阶段，在branch上新建分支，如/branch/yourPrj;此阶段，考虑到会比较频繁的提交、修改产物，所以提交没有那么严格，以快速反应为主

 

(a)第一次release

当第一次release临近时，将/branch/yourPrj cp到trunk，开发人员逐步开始向trunk提交产物，同时确保提交质量

QA前，将/trunk cp到/tags/release，再build，对于bug fix，先merge到release，再build。

 

(b)例行release

以增量开发为例，假定每月release，将trunk上的待发布的revision merge到release,build之。

QA通过之后再打tag(X.X或者$date)，如果是比较重大的release，可以自行特别标识（如release X.0）

 

(c)多个team并行开发

如果多team并行开发，而且feature的粒度比较大（比如超过release周期），可以在branch上建分支，如/branch/module1，待开发完后，合并到trunk，release前，将trunk上的待发布的revision merge到release。

 

3.注意事项

(a)按要求提交产物，保持trunk的stable

(b)所有的build，都是以release为基础产生的，所以，在开发人员在不熟悉代码merge之前，不能随意touch release分支，建议在初期每个team指定人员merge

(c)merge代码会是瓶颈，除了要耐心、细致外，还要有利器--批量merge的脚本