开发中项目的版本管理和svn使用（上）

2017新年伊始，从同事手里接手了原有项目的管理工作，鉴于这个项目版本管理已经陷入史无前例的大混乱，所以打算结合项目开发中版本管理的基本知识，重新梳理项目。

svn的目录结构和使用

现在的项目管理一般使用git或者svn作为版本管理的工具，手上的项目采用的是svn。
整理了一下版本库的目录结构，大概是这样的情况：

逐个解释一下目录下文件对应内容：

• trunk：主开发目录
• tags：版本存档目录
• branches：分支开发目录
• documents：存放文档的目录

而之前约定的情况是这样的，

• trunk：始终跟产线一致的代码
• tags：产线版本存档目录（并没有实际利用起来）
• branches：当前开发分支，可能同时有多个，完成开发后合并到trunk

咋看上去，这个好像也没有什么问题。但在实际开发中却带来了不少麻烦。
首先是trunk代码和tags最新代码重复；然后是branches重复开发和合并导致工作量增大，一旦代码冲突，非常容易出错。仅仅去年一年，项目因为代码合并造成的bug和额外工作量，就造成了多次产线事故和版本延误，简直是不能忍。

那么一个标准的使用规范，或者说比较方便的使用标准应该是什么。

• trunk：最新开发代码
• tag：产线版本的快照（备份）
• branches：另起的开发分支/产线bug修复

那么在实际开发中，仅有一个开发主线的情况是这样的：
在trunk上开发最新的代码，每当一个版本完成，就打包发布版本，这是tag下会有一个打包时的版本快照。版本完成上线后继续在trunk上进行新版本开发，如果产线出现bug，则从tag上拉取一个分支到branches，从branches上修复bug。并且实时关注产线情况，解决后将branches代码合并到trunk即可。
当多个开发主线时：
trunk上开发最近上线的版本，在branches上拉取分支进行其他版本代码的开发。trunk上每上线一个版本，进将下一个最近上线的brunches代码合并到trunk上。其他与仅有一个开发主线情况一致。

开发过程中的测试版本和正式版本

这个比较简单，顺带提一下。
这个项目使用maven管理。版本库有两个分支，snapshot和release。之前项目不适用snapshot，全部采用release生成，导致项目版本库快速庞大，不仅占用资源，也不方便历史版本的追踪管理。正确的使用方式是：
项目组内部测试和集成测试一律生成snapshot版本，产线上线版本生成release版本。
也可以使用jenkins自动化构建，但是这个构建时间比maven长太多且只能生成release版本，不推荐。