Android SVN开发实战的文件夹结构呈现

svn有一个非常标准的文件夹结构，这是。

例如，该项目是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.0开发完成，代码 冻结

基于已经冻结的trunk，为release1.0打tag

此时的文件夹结构为

svn://proj/
+trunk/ (freeze)
+branches/
+tags/
    +tag_release_1.0　(copy from trunk)

2.0 開始开发。trunk此时为2.0的开发版

发现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)

在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发

在1.0 bugfix 完毕之后，基于dev_1.0_bugfix的branch做release等

依据须要选择性的把 dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要依据详细情况）

这是一种非常标准的开发模 式。非常多的公司都是採用这样的模式进行开发的。trunk永远是开发的主要文件夹。

另外一种方法

在每个release的branch中进行 各自的开发。trunk仅仅做公布使用。

这样的开发模式其中，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.0)
+branches/
     +dev_1.0 (开发任务结束。freeze)
+tags/

依据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)

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)

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)

选择性的进行代码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进行主要开发。集中式）：

长处：管理简单

          缺点：当开发的模块比較多，开发人数/小团队比較多 的时候。非常easy产生冲突而影响对方的开发。由于全部的修改都有可能触碰对方的修改。

另外一种开发模式（分支进行主要开发，分散式）：

长处：每 自独立的发展，不easy相互作用。

          缺点：管理复杂，merge很麻烦的时间，easy死。

其实，而不是明显的在这里。许多其它时间两种 模式组合。