版本控制的策划书

版本管理
1版本命名规则
版本号为标志本次下发的最重要的记录，常规下发都视作一次版本的更新。
其命名规则为：
从2015年5月开始，常规下发的命名为1.5.1.0（1代表主版本号，其中5为月份，1代表下发序号，0代表的是常规下发），例如从十二月开始5月9日的下发版本号为1.5.1.0，5月16日的下发版本号为1.5.2.0，5月23日的下发版本号为1.5.3.0，后面的下发版本号按照此规定顺延。紧急下发的命名首先确定一个关联版本，例如本次紧急下发的关联版本为1.5.2.0，那么此次紧急下发的版本号就为1.5.2.1（给予关联版本的序号，修改最后一位不为0代表紧急下发）。
2版本升级原则
版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，提供严格定义的升级方法。
在下面几种情况下，进行版本演化和升级：
1、 当产品发生重大修改和改进时，主版本号加1。
重大修改和改进包括： 1）平台迁移； 2）开发工具的迁移； 3）体系结构的变迁
2、 每周四的常规下发都作为一次版本的更新，按照以上的命令规则来执行。

3目录结构
由于各项目组的实际情况不同，目录结构很难统一，但为了能更好地管理各项目组的文档，建议可将被管理的配置项分为三大类：文档类、源码类及下发包类，这样存放比较清晰，有利于版本管理。
4权限控制
为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。
文档权限类别：只读权限，读写权限。
文档类别：设计文档，源码，发行文档。
用户类别：开发人员、测试人员、业务测试人员、质量管理人员等。
为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于管理，后期会以表格的形式列出人员与管理对象的访问关系（用户权限清单）
5提交规则
一般项目组长在给小组成员分配好开发任务以后，他们应该将自己的任务拆分成一个粒度核实的任务单元去实现，这样完成一个任务单元可以做一次svn的提交，但是在提交前，开发人员务必编译通过自己所有的代码，保证测试通过，能够正确的运行。