1 SVN标准目录
Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是：
这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。
trunk：主干，如果说把一个软件项目从开始到消亡比作一个故事的话，主线情节都在这里被SVN记录着。一般的，所有的开发都是基于trunk。
branches：分支，有很多种用法，比如：版本发布维护分支、新特性开发分支，甚至是缺陷修复分支等等。一般的，应该基于某一发行版本对应的tag做分支（branch）进行开发。
tags：标签，或者叫快照，某个版本发布时候，都在这里留档。
2 集中式：trunk进行主要开发
1. 1.0开发完毕，代码冻结
2.基于已经冻结的trunk,为release1.o打tag
此时的目录结构为：
svn://proj/
+trunk/ (freeze)+ branches/
+tags/
+tag_ release_ _1.0 (copy from trunk)
3. 2.0开始开发，trunk此时为2.0的开发版
4.现在1.0有bug, 需要修改，基于1.0的tag做branch
此时的目录结构为：
svn://proj/
+trunk/ ( dev2.o )+branches/
+dev_ 1.0_ bugfix (copy from tag/release_ _1.o)
+tags/
+release_ 1.0 (copy from trunk)
5.在1.0 bugfix branch迸行1.o bugfix幵炎，在trunk进行2.0开发。
6.在1.0 bugfix完成之后，基于dev_ 1.0_ bugfix的branch做release等。
7.根据需要选择性的把dev_ 1.0_ bugfix拉个分支merge回trunk (什么时候进行这一步操作,要根据具体情况)。
这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录
3 分散式：分支进行主要开发
这种开发模式当中，trunk是不承担具体开发任务的，主要承担版本发布，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。
- 1.0开发 , 做dev1.0的branch
svn://proj/
+trunk/ (不担任开发任务 )
+branches/
+dev_ 1.0 (copy from trunk)
+tags/
- 1.0开发完成, merge dev1.0到trunk
此时的目录结构：
svn://proj/
+trunk/ (merge from branch dev_ 1.o)
+branches/
+dev_ 1.0 (开发任务结束, freeze)
+tags/
3. 根据trunk做1.0的 tag
svn://proj/
+trunk/ (merge from branch dev_ 1.o)
+branches/
+dev_ 1.0 (开发任务结束, freeze)
+tags/
+tag_ release_ _1.0 (copy from trunk)
这其实是一种分散式的开发，当各个部分相对独立一些（功能性的），可以开多个dev的分支进行开发，这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。
所以，第六步进行 选择性的merge，是可以当2.0开发结束后一起把dev_1.0（bugfix用）和dev_2.0（新版本开发用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等之后再merge回trunk。
这两种方法各有利弊，第一种方法是可以得到一个比较纯的dev_2.0的开发分支，而第二种方法则更加的保险，因为要测试嘛。
多人协作时，第六步是最经常出问题的地方，严重的甚至会导致代码被覆盖回滚情况，其原因在于分支管理者创建分支后不再或长时间从主干拉回数据，导致最终合并回主干时分支的文件甚至结构都与主干有较大差别，产生较多冲突。需要人手解决，浪费了很多时间。
针对这个问题，是否有一种方案可以在分支提交时即检测该分支最后一次合并的版本是否与主干版本相符，如果不符则不允许提交，强制要求大家养成从主干拉数据的习惯呢？如果可以实现，那么在分支合并回主干时将几乎可以消灭掉冲突。
当前解决思路主要有3种：
不间断强调使用SVN时要经常从主干同步代码到分支。该方案缺点很明显，完全依赖人工，不可信。
在trunk里单独维护一个带最新版本号的readme.md，每次更新trunk时更新该版本到更新的版本号。此后合并分支回主干时判断下分支时的readme.md是否和主干里的readme.md保持一致，若小于主干，则强制同步主干代码到分支。该方案缺点是需要每次更新主干代码时都要强制手工维护版本号，容易出现低级错误——更新trunk时忘记更新readme.md里的版本号等情况。
SVN本身记录版本更新信息，可以通过在服务器端监控主干，判断提交前(pre-commit)检测是否有分支最后一次合并版本号小于主干版本号，如果小于则不允许提交，强制要求先从主干合并。此方案是一种相对完美的方案。
以上呢，就是SVN的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自的优缺点：
第一种开发模式（trunk进行主要开发，集中式）：
优点：管理简单。
缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动。
第二种开发模式（分支进行主要开发，分散式）：
优点：各自开发独立，不容易相互影响。
缺点：管理复杂，merge的时候很麻烦，容易死人。
最后，推荐第一种开发模式
责职说明：
Trunk：用于各版本开发提交代码
TAG：用于记录和保存每个release/milestone的代码
Branch：用于bug fixing
过程说明：
- 项目开始时，创建Trunk，开始1.0.0开发
- 所有小组成员都往Trunk中提交代码
- 当1.0.0开发完成后，创建一个标签：Tag1.0.0
- Tag1.0.0测试完成后，部署到服务器
- 开发小组开始新版本1.0.1开发，继续提交代码到Trunk中
- 1.0.1开发完成，创建Tag1.0.1，测试完后部署到服务器
- 开发小组开始新版本1.0.2开发，继续提交代码到Trunk中
- 1.0.1运行中发现bug，需要紧急修复 -> 从Tag1.0.1中创建1.0.1bug-fix Branch
- Bug修复代码提交到1.0.1bug-fix Branch，测试通过后，部署到服务器
- 提交到1.0.1bug-fix Branch的代码合并到Trunk中
- And so on……