svn项目管理

目录划分
Trunk：存放项目代码的基线
Tags：暂时不用
Branches：存放各种代码分支。

●DevBranche放开发分支
●TestBranche放测试分支
●ReleaseBranche放发布分支
Document：存放每个版本产生的文档。

其中每个版本分为几个阶段：
●项目计划：存放该版本的任务安排的相关事宜。

●需求分析：存放该版本的相关需求文档，及对需求分析的相关产出。

●开发阶段：存放在开发代码过程中的相关产出。

如SQL
●测试阶段：存放在测试阶段应该具备的产出文档。

如测试用例。

●发布阶段：存放发布阶段具备的文档。

如发布手册
分支管理流程
开发过程中，一般采用版本迭代，并行开发的模式。

理由如下：
1.为了能够适应需求快速上线
2.及时修复线上生产环境的bug
3.快速响应紧急需求
根据以上的背景及目的，对并行版本的分支管理如下
1.在时间A点打出dev-version-01分支
2.在时间B点打出dev-version-02分支
3.随着dev-version-01版本的任务的遂一交付，分别在A-01，A-02打出test分支进行测试
4.当版本的bug全部解决完后，测试结束，则打出realese版本进行版本发布
5.版本发布结束后，当线上环境验收完毕后，需要把该开发分支的代码合并入trunk。

并
通知其余各分支从trunk合并到各开发分支。

版本命名
一般版本管理中会出现几种情况：正常版本，bug修复版，紧急需求版。

针对不同情况版本的命名可如下：
正常情况下的版本命名：ms_项目名_版本号。

如ms_care_2014.01
bug修复版版本命名：ms_项目名_版本号-序号。

如ms_care_2014.01-01
紧急需求版：由于紧急需求一般会跟bug修复版一起发布，命名可同上
分支合并方式
分支合并至trunk：
代码提交的时候注释备注: “从xxx分支合并至trunk”
Trunk合并至开发分支
代码提交的时候注释备注: “合并xxx分支代码”
需要说明的：
每个版本发布完后需及时合并至trunk，并及时合并到开发分支
1.避免各开发版本跨版本合并导致版本冲突严重，无法解决
2.发布的代码需要合并到下个版本做集成测试。

一方面及时发现线上bug，一方面测试可
严重代码合并没有错误。

分支管理图
分支管理图用于跟踪版本分支打出及合并的情况。

版本分支图包含以下几个信息：
1.开发分支的打出时间，当分支被打出的时候需要记录该时间
2.版本发布后，代码合并后需要记录该时间
3.在其他版本合并该次发布的代码后，需要在该图上标注
注意：
1．开发分支只能从trunk打出，不能从其他分支打出
2．只能从开发分支合并到trunk
以上做法遵循，从哪里来回哪里去。

形成线性关系，避免版本间的关系出现网状，造成混乱。

代码格式化器
为了避免代码合并过程中出现大量的冲突，统一使用代码格式化器。

项目的编码
项目代码，包括配置文件统一使用UTF-8。