svn管理模式

一、目前svn的标准目录结构：

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

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

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

 

二、管理模式

1、集中式：trunk进行主线开发 

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

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

举例：刚刚发布版本1.1.0，现在正在开发1.2.0。此次上个版本出现bug需要紧急修复。要在1.1.0的基础上进行bug修正。顺序如下：

（1）1.1.0开发完成，代码冻结。

（2）基于已经冻结的trunk，为release1.1.0打tag。

         此时的目录结构为：

        svn：//project/

                 +trunk/（freeze）

                 +branches/

                 +tags/

                     +tag_release_1.1.0（copy from trunk）

  （3）1.2.0进行开发，trunk此时为1.2.0的开发版本

   （4）发现1.1.0有bug需要紧急修复，基于1.1.0的tag做branch。

         此时的目录结构为：

        svn：//project/

                 +trunk/（dev 1.2.0）

                 +branches/

                    +dev_1.1.0_bugfix(copy from tag/release_1.1.0)

                 +tags/

                     +tag_release_1.1.0（copy from trunk）

       (5)在dev_1.1.0_bugfix分支上进行bug修复，trunk仍然做1.2.0的开发。

    （6）在dev_1.1.0_bugfix完成后，基于dev_1.1.0_bugfix分支拉出一个tag分支：tag_release_1.1.1

     (7) 将dev_1.1.0_bugfix分支的内容merge到trunk上。

     此种模式trunk永远是开发的主要目录。也是目前现状的开发模式。

2、分散式：分支进行主要开发

这种开发模式当中，trunk是不承担具体开发任务的，主要承担版本发布，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。

举例：

 （1）1.1.0开始开发，从trunk上拉取dev1.1.0的branch。

  此时的目录结构：

  svn：//project/

                 +trunk/（不承当开发任务）

                 +branches/

                         +dev_1.1.0（copy from trunk）

                 +tags/

（2）1.1.0开发完成后，merge dev1.1.0到trunk上。

   此时的目录结构：

  svn：//project/

                 +trunk/（merge from dev1.1.0）

                 +branches/

                         +dev_1.1.0（开发任务结束，冻结）

                 +tags/

  （3）根据trunk做1.1.0版本的tag

     此时的目录结构：

         svn：//project/

                 +trunk/（merge from dev1.1.0）

                 +branches/

                         +dev_1.1.0（开发任务结束，冻结）

                 +tags/

                         +tag_release_1.1.0（copy from trunk）

四、两种模式的区别和思考

1、两种模式的共同点是：出现BUG的时候，都需要从tag上拉取分支进行开发。

2、两种模式的区别是：trunk上开发，还是在branch上开发。

由此总结：1、无论选择哪一种方式，一定需要打TAG分支，用于在出现bug回滚，新版本又在开发期间，可以从tag拉取代码进行修复。

                 2、结合jenkins流程化控制管理，项目必须适应的变化:

                                         （1）必须摈弃掉增量手工替换文件的发版方式，每次发版全量替包。

                                         （2）项目使用maven或者ant管理，用于jenkins的自动化构建使用。更推荐使用maven。其有清晰的文件目录以及maven私服来管理第三方依赖包。

                                         （3）如果使用集中式开发，trunk主线，那么测试环境发布trunk主支。在最后一次成功的版本基础上打tag，并且生产环境发布tag分支。

                                         （4）如果使用分散式开发，trunk主线只承当合并。每次新版本都拉取一条或多条branch。版本经理合并branch代码到trunk进行测试。测试环境发布trunk分支。

                                                 最后一个成功版本打完tag后，可以直接将镜像推送到habor生产进行发布。

五、后续优化事项

1、引入jira，设想在jira上新建版本管理。版本统筹任务，svn提交的pre-commit对任务的状态进行判断，如果任务已经终结，测试需要将相关bug重新录入任务。

      严格的svn代码提交控制。

2、使用jenkins自动生成tag版本。

ps：所谓严格代码控制，都是为了让开发对发版存有敬畏之心！