`Subversion` 有一个很标准的目录结构: ```bash project ├── trunk ├── branches └── tags (此目录只读) ``` 这个标准的目录结构我们在大多数的开源项目中都能看到，这是因为基于这套标准目录结构为软件开发提供了一种非常好的宏观版本库管理机制（特别是在产品类项目中）。 `trunk` 为主开发目录，`branches` 为分支开发目录，`tags` 为存档目录（不允许修改）。 * 1.Trunk Trunk中文翻译为“主干”的意思，在项目运作过程中，日常的开发和管理资料都在此目录中进行维护和更新。 * 2.Branches Branches的中文意思为“分支”，在项目运作过程中，存放阶段性成果（版本），这些阶段性成果是可维护（包括为客户定制化的版本）。 * 3.tags tag的中文意思为“标签”，此目录为一些阶段性成果进行存档。为只读目录，不允许进行修改。 对于这几个开发目录，一般的使用方法有两种。 ###### 1.从软件产品的角度出发（比如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` 此时的目录结构为 ```bash project ├── trunk/ (freeze) ├── branches/ ├── tags/ └── tag_release_1.0　(copy from trunk) ``` 2.0 开始开发，`trunk` 此时为 2.0 的开发版 发现 1.0 有bug，需要修改，基于 1.0 的 `tag` 做 `branch` 此时的目录结构为 ```bash project ├── trunk/ (dev 2.0) ├── branches/ │ └── dev_1.0_bugfix (copy from tag/release_1.0) └── tags/ └── tag_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` 永远是开发的主要目录。 ###### 2.第二种方法 在每一个release的branch中进行各自的开发，trunk只做发布使用。 这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。 暂不过多介绍，to be continued..