一、SVN 日常的两种开发模式

基本svn项目结构

Subversion有一个很标准的目录结构，是这样的。比如项目是 proj，svn地址为 svn://proj/，那么标准的 svn 布局是：

这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。

trunk：主干，如果说把一个软件项目从开始到消亡比作一个故事的话，主线情节都在这里被SVN记录着。

branches：分支，有很多种用法，比如：版本发布维护分支、新特性开发分支，甚至是缺陷修复分支等等。

tags：标签，或者叫快照，某个版本发布时候，都在这里留档。

集中式(trunk进行主要开发)

一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。

此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。

例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。按照时间的顺序：

这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

分散式：分支进行主要开发

这种开发模式当中，trunk是不承担具体开发任务的，主要承担版本发布，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系如下所示：

这其实是一种分散式的开发，当各个部分相对独立一些（功能性的），可以开多个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中.

二、集中式开发模式在CornStone的具体实现

简单介绍下cornerStone的操作面板

这里笔者用的是cornStone 3 V3.0.2版本

check out 、update 、commit 这些操作就不说了，这些操作我们日常使用中再熟悉不过了，这里讲下 Tag 与 Branch 以及 Merge 这些操作怎么使用。
Tag 与 Branch 以及cheakOut操作是基于服务器目录的，而update 、commit 以及Merge这些是基于我们本地的工程目录。

当一个工程从公司的服务器上checkout下来我们就可以看到以上的目录结构，cornstone比较形象化，上面那个服务器样的图标就是服务器上的目录，下面那个就是你本地工程的文件地址。明白这个下面的操作就比较好做了。

具体实现步奏：

我们本地新建一个工程命名为svnDevTest并Import到服务器工程目录trunk下
在本地工程进行dev_v1.0版本开发,开发完毕打包工程，点击cornstone 左侧服务器目录并点击project/iOS/trunk/svnDevTest 这时候 tag 与 branch 会从不可点击状态变为可点击状态，

点击tag在弹出的菜单中，填好tag打包的名称(release_v1.0)，并选择好打包的服务器文件路径(这里是project/tag).

这时候项目需要做V1.1版本的开发，开发途中用户使用发现V1.0项目有Bug急需处理，V1.1版本还不到能上架发布的程度，这时候我们就可以用branch操作将我们之前发布的project/tag/release_v1.0做一个分支放到project/branch目录下并将分支工程命名为bugfix_V1.0,branch操作和tag操作一样，这里就不再描述了。这时候我们的工程目录就会像下面这样。
V1.0版本问题解决，准备打包V1.1版本。这时候我们需要将我们在bugfix_V1.0的改动合并到我们的主干开发中来(即trunk目录),点击cornstone 左侧目录并选择我们本地trunk目录下的工程，点击Merge在弹出的菜单中选择我们需要合并的分支，有冲突的话处理冲突，处理完后(也就是说bugfix_V1.0对1.0版本问题的修复代码已经合并到开发主干上(trunk))就可以将合并的改动commit到主干上了。