最近在进行项目的版本目录管理，借鉴了SVN目录文章，转之：
Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是
svn://proj/
|
+-trunk
+-branches
+-tags
这 是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使 用，svn并没有明确的规范，更多的还是用户自己的习惯。
对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发 （比如freebsd），因为互联网的开发模式是完全不一样的。
第一种方法，使用trunk作为主要的开发目录。
一般的，我们的所有的开 发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码 处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk 进行开发。此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。例 如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
按照时间的顺序
1.1.0开发完毕，代码 冻结
2.基于已经冻结的trunk，为release1.0打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/ ( dev 2.0 )
+branches/
+dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
+release_1.0 (copy from trunk)
5.在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发
6.在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等
7.根据需要选择性的把 dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）
这是一种很标准的开发模 式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。
第二种方法，在每一个release的branch中进行 各自的开发，trunk只做发布使用。这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经 release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。
1.1.0开发，做 dev1.0的branch
此时的目录结构
svn://proj/
+trunk/ (不担负开发任务 )
+branches/
+dev_1.0 (copy from trunk)
+tags/
2.1.0开发完成，merge dev1.0到trunk
此时的目 录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (开发任务结束，freeze)
+tags/
3.根据trunk做1.0的tag
此时的目录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (开发任务结束，freeze)
+tags/
+tag_release_1.0 (copy from trunk)
4.1.0开发，做dev2.0分支
此时的目录结构
svn://proj/
+trunk/
+branches/
+dev_1.0 (开发任务结束，freeze)
+dev_2.0 （进行2.0开发）
+tags/
+tag_release_1.0 (copy from trunk)
5.1.0有bug，直接在dev1.0的分支上修复
此时的目录结构
svn://proj/
+trunk/
+branches/
+dev_1.0 (1.0bugfix)
+dev_2.0 （进行2.0开发）
+tags/
+tag_release_1.0 (copy from trunk)
6.选择性的进行代码merge
这其实是一种分散式的开发，当各个部分相对 独立一些（功能性的），可以开多个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的 开发分支，而第二种方法则更加的保险，因为要测试嘛。
以上呢，就是我说的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自 的优缺点
第一种开发模式（trunk进行主要开发，集中式）：
优点：管理简单
缺点：当开发的模块比较多，开发人数/小团队比较多 的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动
第二重开发模式（分支进行主要开发，分散式）：
优点：各 自开发独立，不容易相互影响。
缺点：管理复杂，merge的时候很麻烦，容易死人。
其实，这里并没有一定之规，更多的时候是两种 模式结合使用。
本节向大家讲解一下SVN目录结构组成，之前几节我们学习了SVN库的目录结构相信大家应该掌握了，在这里和大家简单介绍一下SVN目录结构组成，欢迎大家一起来学习。
首先看一下下面的这个结构。
wolfwebadmin
├─ProjectManagement
│├─trunk
│├─branches
│└─tags
└─SSO
├─trunk
├─branches
└─tags
大概的说一下,ProjectManagement和SSO是两个项目trunk是开发的主线代码,存放能够运行的正确的代码;程序员如果开发新的程序或者改bug,一般要先branch(SVN的一个功能)trunk目录下的代码到branches目录的一个子目录,在那里对代码进行修改,确认无误后再提交到trunk主线下(但是有的时候为了效率,我们也多人都在trunk目录下开发项目).tags目录可以看做主线代码的快照,比如你做了1.0又做了2.0,那每个不同版本的代码你就做快照放到tags文件夹下了。
一个Subversion版本库实现了一种版本化的文件系统，版本库只是一个包含目录和文件的文件系统，而且它的文件系统是版本化的，并且实现了”廉价”拷贝，让它的这种操作比传统文件系统便宜很多，但是版本库本身还是像一个文件系统：Subversion本身没有特别的目录或名称用来代表trunk或branches，他们只是文件系统的普通目录，这依赖于你给这些目录名和结构的一种意义。也就是说，社区已经采纳了多种普通的布局作为最佳实践，因此一个人可以将其视为推荐方式。如果你的版本库是公共访问的，根据这些习惯，用户可以方便的访问版本库来查找他们所需要的。
有两种常见的SVN目录结构布局：
trunk
branches
tags
第一种布局是版本库包含一个项目或一组紧密联系项目的最佳选择，这个布局非常好用，因为分支与标签整个项目或一组项目会非常简单，只需要一个简单的命令：
svncopyurl://repos/trunkurl://repos/tags/tagname-m“Createtagname”
这可能是最常用的版本库布局，被许多开源项目采用，就像Subversion本身和Subclipse，这是大多数主机站点，如Tigris.org,SourceForge.net和GoogleCode遵循的方法，这些站点的每个项目有自己的版本库。
另一种SVN目录结构布局是针对一个版本库包含不相关项目的最佳选择。
ProjectA
trunk
branches
tags
ProjectB
trunk
branches
tags
在这种布局里，每个项目会存在顶级目录里，然后该目录之下创建trunk/branches/tags，其中与第一种布局相同，这只是将项目放到自己版本库方式的替换，他们都在一个版本库中。Apache软件基金会使用这种布局方式来存放他们的所有项目在一个版本库。
通过这种布局，每个项目都有自己的分支和标签，可以很容易使用一个命令创建分支和标签，就像前面展示的：
svncopyurl://repos/ProjectA/trunkurl://repos/ProjectA/tags/tagname-m“Createtagname”
这种布局可以简单的创建同时包含ProjectA和ProjectB的标签，你可以这样做，但是需要多个命令，你也要决定是否创建一个特别的目录存放这种分支和标签，如果你需要经常这样做，你或许应该考虑第一种SVN目录结构布局。
至于版本库中目录的名称，再说一遍：只是一种习惯，他们在Subversion中没有特别含义。
“trunk”可以认为是项目的开发主线，你可以称之为“main”，”mainline”，”production”或任何你喜欢的名字。
“branches”是放置分支的地方，人们因各种目的使用分支，你或许希望通过特性分支或客户修改分支来隔离你的发布或维护分支等，在这个例子里，你可以在branches创建一层目录，或只是在顶级目录创建多个分支目录。
“tags”也不会被Subversion特别对待，他们只是习惯，或许通过钩子脚本或授权规则进行强制，来指明你创建了一个时间点的快照，通常情况下tags与分支的区别就是tags一旦创建不能修改，你也可以将标签目录叫做”releases”，”snapshots”，”baselines”或任何你喜欢的。
记住，名称对你有意义，不是Subversion。最后，Subversion的架构，全局修订版本经常使得标签没有必要，我不知道只是因为要创建tag而创建tag有什么意义，如果你需要在特定时间点重建软件，你可以通过svnlog来确定相关的修订版本号。tags对于版本库的”外部”用户很有用，或许QA/Release团队需要执行构建，或许是一个内部开发小组希望在另一个产品使用发布版本，或是外部用户或客户希望根据字面含义从版本库获取发布快照，在这些场景中，创建tag是保证获取正确代码的最简单方法，也需要有好的交流机制来指明发布快照。
希望本文可以为你澄清一些问题，让你更好的理解Subversion是如何工作的。最后，我希望指出Subversion版本库的布局是可以修改的，你可以一直重组和重构布局，最坏情况下，会让用户调整他们的工作拷贝，但不会让你从头再来，你应该自由的改名，移动目录或任何你希望改变版本库的方式去做。本节关于SVN目录结构讲解完毕，请关注本节其他相关报道。
本节和大家讨论一下SVN库的目录结构问题，这里我发表一下个人理解，和大家讨论讨论，欢迎大家一起来学习SVN库的目录结构方面的知识。
1、所有项目都在一个SVN库中么？
对于这个问题，个人认为，应该每个项目建一个SVN库，为什么这样说呢，因为SVN是全局版本，假如SVN库是如下结构：
SVN库<全局版本1.1>
┠项目A<1.1>
┖项目B<1.1>
这就会导致任何一个项目修改，影响全局版本修改，不能真实反映单个项目的版本情况。
2、SVN库的目录结构该怎样规划？
参考了国外一些主要的开发网站，如SourceForge，大同小异，类似这样的目录结构：
SVN库
┠tags(发布)
┃├1.1rc1
┃├1.2
┃├1.5
┃└1.9
┠trunk(主版本)
┃└project
┃├src
┃├classes
┃└WEB-INF
┖branches(分支)
└分支
主要的开发工作放在trunk，分支放在branches，发布版本放在tags。
存储库
┠项目名
┃├trunk：主版本
┃├branches：分支版本（独立版本）
┃└tags：标记版本，比如发行版v1.0/v2.0等等
3、SVN库的管理原则：
1、项目负责人和版本管理员负责架构项目目录结构，包括配置文件、第三方JAR文档
2、项目负责人分配开发人员目录权限，由版本管理员负责实施，权限分配粒度要细
3、trunk,tags,branches,项目负责人、协同版本管理员构建tags和branches
4、版本管理员负责解决开发人员在开发过程中的有关版本问题
5、开发人员每次修改，或者新增、删除、拷贝工作区对象后，应该立刻提交到版本库，有效保持工作区与资源库的高度一致，每天下班之前提交、（更新）
6、开发人员在每次修改工作区中代码或者文档时，首先更新该对象，可以尽量减少冲突、合并
7、保证提交到的版本库的代码没有BUG以免影响开发组，可以适当利用加锁机制，减少冲突
8、项目负责人和版本管理员负责软件的测试版，构建测试环境，branches由版本管理员进行（checkout）
9、项目负责人和版本管理员负责发布软件的发布版，与系统部协调构建发布环境(export)
10、版本管理员负责清理有关不需要的branches,tags。本节关于SVN库的目录结构讲解完毕。