SVN版本管理：两种开发模式

1 SVN标准目录

Subversion有一个很标准的目录结构，是这样的。好比项目是proj，svn地址为svn://proj/，那么标准的svn布局是：

这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不容许修改）。可是具体这几个目录应该如何使用，svn并无明确的规范，更多的仍是用户本身的习惯。

trunk：主干，若是说把一个软件项目从开始到消亡比做一个故事的话，主线情节都在这里被SVN记录着。

branches：分支，有不少种用法，好比：版本发布维护分支、新特性开发分支，甚至是缺陷修复分支等等。

tags：标签，或者叫快照，某个版本发布时候，都在这里留档。

示例如图：

2 集中式：trunk进行主要开发

通常的，咱们的全部的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制做安装程序、打包等）结束后，代码处于冻结状态（人为规定，能够经过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。

此时，若是发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）没法知足时间要求，这时候就须要在上一个版本上进行修改了。应该基于发行版对应的tag，作相应的分支（branch）进行开发。

例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。按照时间的顺序：

这是一种很标准的开发模式，不少的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

3 分散式：分支进行主要开发

这种开发模式当中，trunk是不承担具体开发任务的，主要承担版本发布，一个版本/阶段的开发任务在开始的时候，根据已经release的版本作新的开发分支，而且基于这个分支进行开发。仍是举上面的例子，这里面的时序关系是。

这实际上是一种分散式的开发，当各个部分相对独立一些（功能性的），能够开多个dev的分支进行开发，这样各人/组都不会相互影响。好比dev_2.0_search和dev_2.0_cache等。可是这样merge起来就是一个很痛苦的事情。

因此，第六步进行 选择性的merge，是能够当2.0开发结束后一块儿把dev_1.0（bugfix用）和dev_2.0（新版本开发用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等以后再merge回trunk。

这两种方法各有利弊，第一种方法是能够获得一个比较纯的dev_2.0的开发分支，而第二种方法则更加的保险，由于要测试嘛。

多人协做时，第六步是最常常出问题的地方，严重的甚至会致使代码被覆盖回滚状况，其缘由在于分支管理者建立分支后再也不或长时间从主干拉回数据，致使最终合并回主干时分支的文件甚至结构都与主干有较大差异，产生较多冲突。须要人手解决，浪费了不少时间。

针对这个问题，是否有一种方案能够在分支提交时即检测该分支最后一次合并的版本是否与主干版本相符，若是不符则不容许提交，强制要求你们养成从主干拉数据的习惯呢？若是能够实现，那么在分支合并回主干时将几乎能够消灭掉冲突。

当前解决思路主要有3种：

1. 不间断强调使用SVN时要常常从主干同步代码到分支。该方案缺点很明显，彻底依赖人工，不可信。

2. 在trunk里单独维护一个带最新版本号的readme.md，每次更新trunk时更新该版本到更新的版本号。此后合并分支回主干时判断下分支时的readme.md是否和主干里的readme.md保持一致，若小于主干，则强制同步主干代码到分支。该方案缺点是须要每次更新主干代码时都要强制手工维护版本号，容易出现低级错误——更新trunk时忘记更新readme.md里的版本号等状况。

3. SVN自己记录版本更新信息，能够经过在服务器端监控主干，判断提交前(pre-commit)检测是否有分支最后一次合并版本号小于主干版本号，若是小于则不容许提交，强制要求先从主干合并。此方案是一种相对完美的方案。

以上呢，就是SVN的两种开发模式了，具体哪一种好，并无定论。这里大体的说一下各自的优缺点：

第一种开发模式（trunk进行主要开发，集中式）：

优势：管理简单。

缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。由于全部的改动都有可能触碰对方的改动。

第二种开发模式（分支进行主要开发，分散式）：

优势：各自开发独立，不容易相互影响。

缺点：管理复杂，merge的时候很麻烦，容易死人。

4 最后，推荐第一种开发模式

责职说明：

Trunk：用于各版本开发提交代码

TAG：用于记录和保存每一个release/milestone的代码

Branch：用于bug fixing

过程说明：

1. 项目开始时，建立Trunk，开始1.0.0开发

2. 全部小组成员都往Trunk中提交代码

3. 当1.0.0开发完成后，建立一个标签：Tag1.0.0

4. Tag1.0.0测试完成后，部署到服务器

5. 开发小组开始新版本1.0.1开发，继续提交代码到Trunk中

6. 1.0.1开发完成，建立Tag1.0.1，测试完后部署到服务器

7. 开发小组开始新版本1.0.2开发，继续提交代码到Trunk中

8. 1.0.1运行中发现bug，须要紧急修复 -> 从Tag1.0.1中建立1.0.1bug-fix Branch

9. Bug修复代码提交到1.0.1bug-fix Branch，测试经过后，部署到服务器

10. 提交到1.0.1bug-fix Branch的代码合并到Trunk中

11. And so on……