Subversion在创建项目的时候默认有两个目录结构选择：
第一种模式：svn://proj/|
第二种模式：svn://proj/|+-trunk+-branches+-tags
第一种模式是一种单一目录结构，集中式管理方式，适合于个人或者流程单一化的协作方式，且各自的创造都是相对隔离，很少存在同时两个人同时修改一个文件的现象。
第二种模式是一种多目录结构，也是集中式管理，但适合与多样化的协作方式，更适合团队进行文档方面的修改协作。该模式可以将SVN的功能发挥到极致。其中 trunk,branches,tags这种分类模式是从时序发展的方式进行分割分类的。（原则上，任何项目都是个时间迭代规划的，所以该分类是合理的且应用比较广泛）
第一种模式相对简单，会简单的Check Out(签出)，Update（更新）,Submit（提交），简单的解决冲突合并问题即可。然而第二种方式相对较为复杂一些，也存在一些多样的变体方式，下面本人以自己的经验总结一下常规约定的项目协作目录说明:
doc:
项目进度过程中的一些记录文档。
src:
项目开发过程中的一些引用包。
code:
项目开发过程中的代码。
开发模式说明:
项目进行持续集成，代码基于Branches[分支]下修改，Tags[发布标记]下发布，Trunk[主干]下为可运行的一个最干净的环境。
项目角色:
发布标记:运维人员（开发）对其负责
分支:开发设计人员对其负责
主干:主管对其负责
项目周期:
0.项目基于trunk下创建分支进行开发
1.（每天）开发人员每天晚上对分支代码进行提交
2.每周(一)开发人员获取一次，决定是否对其代码进行有必要的更新
3.每周五主管对所有分支进行适当的合并操作，以确定代码的合理性和必要的修正来防止项目退化。
4.每个月（一号）项目主管收集问题，沉淀知识和必要的开发过程中的规范，以进一步指定开发计划，推动团队的进步。
5.每年根据公司的发展方向来调整优化开发框架和必要的开发工具的升级。
项目版本号说明:
N(Trunk).N(Branches).N(Tag)
Bug修复说明:
明确定义:项目中未实现的功能不能称之为Bug,而是实现了相关功能在本身有错误而造成的功能不正常、体验不佳、死机、数据丢失、非正常中断等现象。
修复过程说明:制定基于发布出去的Tag版本号进行+1的版本修复版本，修复过程中请基于Branches下修复，以持续迭代的方式进行发布。