SVN管理

一般在进行项目开发的时候，我们都会用到SVN作为源代码管理工具。这里我想记录下我们项目中一般对于SVN项目管理的一些经验。

先分析SVN目录。
Project
-- trunk
-- branch
-- tag
-- release


    一般我们在trunk下进行开发。可以理解trunk就是我们项目的主线，这条线是一直进行并向后延伸的。当我们的项目开发到一定的milestore的时候，我们或许会有要求发布一个beta版本，这个时候我们会从trunk下打一个tag包到tag下并给其一个版本号。这里说到版本号，我想介绍下版本号的定义规则。版本号一般是这样构成：bigVersion.smallVersion.fixVersion。我们一般是这么理解的。当一个产品需要发布的时候我们都会给这个产品定义一个大的版本号，可以从1开始也可以从0开始，这个自己可定。每个版本中都会在设计上或者规划上有子产品，这样就会有其smallVersion，当然，我们不能保证每个版本出来都是没有bug或者需求更改的，于是会有第三个version标识:fixVersion。
    好，我们现在将我们的第一个版本发布到了tag，请注意tag中只有我们项目的源代码，这个时候是我们的第一个版本的一个终结点，必须得保证我们的这个tag中源代码版本是能够正常编译并运行的。提到这里，我们项目一直是使用hudson来进行CI控制的，也就是持续集成，保证每天大家提交的代码都可以正常编译发布。稍后我会写点心得来描述下CI工具，包括hudson和CC。不扯远了，回到tag上面来，tag发布前确定了日期，我们也可以通过SVN来控制在trunk上的提交权限，保证在tag打包前我们测试通过的版本不会因为后期程序员持续在trunk下开发提交代码给它带来的版本上的污染。tag发布后，我们第一个版本结束，但是很显然我们不能保证程序在第一个版本中不会出现BUG，这个时候怎么办呢？这个版本的bug我要Fix就必须从tag源码包中打一份到branch目录，负责相应模块的程序员将在branch上对其所属的bug进行修复，这里修复的bug肯定不会再在这个版本上得以体现了，如果只是针对这个版本的bug修复我们可以定义一个新的fixVersion在下次发布产品的时候进行修复。程序员修改完bug后，在branch上面mege到trunk下面去，这样我们的trunk永远保证的是一条主线在行进，因为有bug的修改bug到trunk上来，没有bug的继续在trunk上进行新功能的开发。这样trunk永远是动态进行的。我们在项目管理的时候也会主要关注trunk的进度并制定我们的任务。
    这里还有一个文件夹没有提到就是release，它是做什么用的呢？release顾名思义是发布，我们将我们的tag下的源代码打包成一个应用ear,war或者甚至是可执行的程序到release下，我们的QA直接从release下获取我们的产品包，进行测试，这里将程序员使用的和QA使用的完全分离也是有一定的好处，QA完全可以从源代码构建中脱离，这些也都可以理解为程序员构建需要考虑的BUG范围之内，所以QA主关注release包中最终将要奉献给用户的产品。

    以上是我的SVN管理的一些理解，如果有什么不对或者不全的地方，也请大家提出来。我们一同探讨。