基于SVN分支开发模式流程浅析

在使用svn多人协作开发式一般采取的工作方式如下：

检出库 创建并维护开发分支 定期将主干代码合并回分支，保证数据完整性，避免最终合并回主干时出现冲突 分支测试 将分支合并回主干 主干提交、部署 多人协作时，第三步是最经常出问题的地方，严重的甚至会导致代码被覆盖回滚情况，其原因在于分支管理者创建分支后不再或长时间从主干拉回数据，导致最终合并回主干时分支的文件甚至结构都与主干有较大差别，产生较多冲突。需要人手解决，浪费了很多时间。

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

当前思路主要有3种：

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

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

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