转自：http://www.cnblogs.com/BraveCheng/archive/2012/07/02/2573617.html
协同开发中SVN使用规范试用
目标，要求
本次svn提交规范主要针对当前项目中出现的svn管理难，开发流程控制难掌控，项目进度记录不准确等问题而提出。要求每个角色都要进行规范化svn作业。
目录结构与开发模式
分散式分支开发模式原理
Svn://project/
+trunk/（主开发目录）
+branches/（分支开发目录）
+dev_1.0_function1（功能性分支1）
+dev_2.0_function2（功能性分支2）
…
+tags（存档目录，不允许修改）
a) 1.0的开发，做一个dev_1.0的功能性分支
Svn://project/
+trunk/（不承担开发任务）
+branches/
+dev_1.0_function1
+tags
b) 1.0功能开发完成，合并分支到主干
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（开发任务结束，冻结）
+tags
c) 测试完成，根据主干做一次1.0的tag
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（开发任务结束，冻结）
+tags
+tag_release_1.0（copy from trunk）
d) 1.0版本结束，做下一个版本的开发2.0
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（开发任务结束，冻结）
+dev_2.0_function2（2.0的开发）
+tags
+tag_release_1.0（copy from trunk）
e) 1.0版本出现bug，直接在dev_1.0版本上修复
Svn://project/
+trunk/（merge from branch dev_1.0_function1）
+branches/
+dev_1.0_function1（bugfix）
+dev_2.0_function2（2.0的开发）
+tags
+tag_release_1.0（copy from trunk）
f) 选择性的进行代码合并
使用规范
命名规范
分支名称采用固定名称与下划线结合方式进行功能性分支描述如:dev_1.0_crm。
存档名称统一采用tag_release_版本的方式。
提交规范
一、 提交之前先更新
在每次提交文件的时候，先进行必要的更新操作，因为，有可能在你修改文件的期间，别人也修改了同样的文件，那么本次的提交很可能会失败。
二、 保持原子性的提交
每次提交的时间尽可能的短，如当你修改了UI界面，完成了功能小细节，确认了bug完善就提交代码。
三、 不要提交本地配置文件，自动生成的文件，自己不明白的文件
本地环境因人而异，因此就有了不同的配置文件，缓存生成文件等，在提交的时候，尽可能检查提交的内容是否是包含了类似不必要的文件。
注释规范
每次提交必须书写明晰的标注
在项目中，如果没有注释，会导致管理人员不能清晰的把握每次的项目提交的概要，bug管理与文件不对称，难以掌控项目的进展等问题，因此建议填写注释，同时不能填写一些无效，无用的信息。填写好的注释应该是能概要的描述所提交的文件的基本功能的信息，也建议使用下面的规范。
注释规范写法，提交前加注释标签
Todo： 任务清单
对于需求性的功能使用todo前缀标签，如加入经纪公司模块，使用类似以下语句：Todo： 增加经纪公司模块
Bugfix:： bug修复
对于系统bug,等信息提交前加上bugfix标签，如修复待遇显示不正确：Bugfix: 修复期望工资待遇显示错误bug
Junk: 零碎碎片
其他的一些无效的信息修改，如静态资源的压缩：Junk： css，js文件压缩
效果图：
