svn方式开发最大的问题就是当n个人开发不同的feature，又来回影响时候，基本上就只能使用branch了，否则就玩完了。这时候就得靠DVCS了。而对于所有的DVCS，都是天然的支持轻量级分支，或者天然的就应该按照分支进行开发。

我们可以按照如下的方法开发
假设服务器是  /server/repo
我们在开发的时候不是想svn一样使用checkout来创建本地工作区，而是在本地做一个服务器代码库的分支，然后进行本地开发。以bzr为例子就是
bzr branch /server/repo [local_proj_name]
这时候这个local_proj_name是一个服务器工作区的分支，可以进行开发了，并且所有的提交都是本地的，不会影响到服务器的工作区。

如果你和别人一起共享一个服务器的代码库，随时获取最新的代码，在svn里面是使用update，在这里是使用pull，如果出现了和本地的冲突，哪么就需要使用merge来进行合并了。
等你在本地工作区都开发好了，也本地提交好了，哪么使用push在传回服务器的代码库就可以了。

这里我想说一下pull和merge的区别。
pull的意思是把代码同步成为服务器代码库的代码，并且版本号也发生变化。pull操作成功后，本地就是一个提交后的状态。
merge的意思是把服务器代码库的代码，合并到本地，此时仅仅是内容的变化，版本是不会发生变化的。所以merge之后，本地是一个修改后的状态，还需要提交一次，本地才是一个提交后的状态。

比如
服务器代码库只有一个文件，叫做readme.txt，
在版本是9的时候，readme.txt的内容是No。
版本号码是10的时候，内容是Yes。

如果我本地的工作区，是从版本号码为9做的本地分支。
我现在pull下来，哪么我本地readme.txt的文件的内容是Yes，本地分支版本号码是10，处于以提交状态。
如果是merge下来，哪么本地readme.txt的内容是Yes，本地分支版本号码是9，处于已修改状态，需要自己提交以下，是本地的版本号码达到10。

跟大家说一下用法，比如我们要把分支merge到主干上

# svn merge –help
merge: Apply the differences between two sources to a working copy path.
usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
       2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]
       3. merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]

我们以第一个为例
merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
这个help里面提示，merge需要三个参数
sourceURL1，sourceURL2的含义并不是两个分支，或者一个分支一个主干，而是同一个分支的两个状态，或者说是两个版本。对这两个版本做一个diff，然后把diff的结果，应用到最后的参数WCPATH上，WCPATH代表是一个本地已经checkout的工作区

svn merge的思想是diff and apply

比如，我开发一个项目叫做proj
目录结构是
proj/trunk
proj/branches
proj/tags

(省略了http:// 之后的，只是相对路径，但是真正使用时候不能省略)

当版本达到100的时候，我决定做一个branch进行一些其他开发

bzr的基本语法是
bzr 命令 [参数]

首先创建一个代码仓库
#bzr init-repo –no-tree ftp://user@host/repo-name
这里使用了ftp作为代码仓库的中心服务器，bzr支持的协议有很多ftp，sftp,http,bzr等等，我这里使用了ftp为了方便。
命令init-repo是创建代码仓库的命令，–no-tree是说明这个代码仓库本身的物理位置是不参与开发的。

然后创建项目，更精确的说是创建一个分支
#bzr init ftp://user@host/repo-name/proj1-trunk

然后checkout代码
#bzr checkout ftp://user@host/repo-name/proj1-trunk proj1
然后就是熟悉的场景了，可以随意的使用，折腾，捣乱，然后commit到中心代码库。其他的使用者也可以随时update获取最新的代码。
怎么样，跟svn一样吧，甚至连基本的命令都一样，比如commit/ci，update/up，revert，info，state/st。

这里面要注意一个问题，就是使用init命令创建的是一个分支，一个branch。
branch在bzr当中是非常重要的，如果你了解一些svn详细的东西，你会发现被管理的每一个目录都有一个叫做.svn的目录，也就是我们可以认为从任何的子目录开始都是一个完整的可以被单独checkout的小项目。而bzr则不然，他只是在每一个branch的目录下才有一个.bzr目录，也就是从这一点开始，才是branch的根，下层的任何目录都不能成为一个单独的独立结构。
而这个branch是需要用init命令搞定的，不能想svn里面一样随随便便的就创建一个目录就完了。

所以从这里我们看出，bzr是完全可以按照svn的思想来使用bzr。不过，这不就没意义了，我为什么不直接用svn呢，所以我们在使用bzr的时候，还是有一些区别的，下篇再说。

假设一个场景
一个项目要进行开发，

• A是底层核心功能开发人员，他要对底层进行开发，并且在第一时间所有的人都要获取他的代码
• B是功能开发人员，进行一个feature1的开发
• C，D是功能开发人员，进行另外一个feature2的开发
• feature1和feature2要公用部分代码，比如同一个接口文件，并对他进行修改

假如我们用svn进行开发，这里面是有一个问题的，因为A的存在，feature1和feature2的开发并不能完全分开，而在开发阶段B，C，D三个人都不能随意的提交代码，否则feature1和feature2都会相互影响。如果他们真的都是分开的功能也没问题，但是因为C，D是一个feature的负责人，他们之间必须要进行代码交换，而因为svn是集中式开发，那么他们应该，必须，也只能通过svn进行代码交换。
如果

1. C提交代码，要求D更新代码
2. A提交代码，要求所有人更新代码
3. D获取代码，A和C的，是正确的代码
4. B获取代码，死菜了，因为C的代码是他不需要的，会影响他的工作，甚至都无法编译通过

这个是一个很普遍的场景，尤其是对人数多一些的小组。那么我们应该如何避免这种情况的发生呢？答案是使用DVCS系统，也就是分布式代码管理系统，例如bzr，hg等。

DVCS的出现可以方便的解决这类问题。与svn等传统VCS系统不同，DVCS并不需要一个中心服务器，每个人的开发工作区都可以认为是中心服务器。DVCS的基础是分支，每需要一个开发工作区，都是基于已有的某个开发工作区创建一个分支，然后开发，然后进行分支的代码merge。因为这种特性，DVCS的分支操作代价非常小。当然对于管理，发布等等我们还是需要一个中心服务器的，那么我们只要一个放在中心服务器的分支就足够了，使用完全相同的技术和下面的各个开发工作区进行代码交换。从技术上，他们的地位是完全等同的。
根据这些，我们再使用DVCS假设一下上述的开发场景

1. 在中心服务器创建技术开发版本
2. A，B，C，D分别根据中心服务器创建自己的开发分支
3. A进行开发，每个阶段，B，C，D基于A提供的代码进行merge，比如A自己架设一个（临时的）ftp
4. C进行开发，每一阶段，D基于C提供的代码进行merge，相对D的开发来说，情况一样。他们的开发完全不影响B的开发
5. 最终都开发完成，一并merge回中心服务器

这就非常顺利的避免了上面遇到的问题。而且，DVCS因为是把自己的工作区认为是代码仓库（repository），所以可以随时的提交代码，随时记录自己的开发变更。而这个在svn当中有时就比较头疼，如果一个feature要开发时间比较长，那么中间的每一个小阶段的代码就很难记录了。

当然了，你可以说，我在svn当中采用给每个人开分支的方法解决这个问题。bingo，没错，但是，这已经就是DVCS的思想了，不是么？那么为什么不用一个现成的DVCS工具呢？

这个privates目录如何使用呢？我们首先在下面建立自己的目录，比如/privates/yinwm，此时我的所有的私有文件都应该放在这里。然后再根据自己所要开发的目录结构（trunk还是分支）建立对应的目录，比如/privates/yinwm/trunk，/privates/yinwm/dev_1.0。
使用IDE，checkout这个目录，此时这个目录下是任何文件都没有的，并且它只属于你自己。当成功的checkout之后，建立外部定义，让一个内部目录（我喜欢起名字叫proj）指向对应的开发目录（trunk或者某一个branch）。再update，你的代码就下来了。此时你再通过IDE上传东西，代码会放在对应的代码区域，而配置文件会放入你自己的私人文件夹。这样就不会相互影响了。

目录结构如下：
svn://proj/
            +trunk/
            +branches/
                      +dev_1.0
                      +dev_2.0
            +tags/
            +privates/
                       +yinwm/
                                 +trunk/
                                          +.classpath等 （IDE文件）
                                          +proj （外部定义，指向trunk）
                                 +dev_1.0/
                                          +.classpath等 （IDE文件）
                                          +proj （外部定义，指向branches/dev_1.0）
                       +xxx

这样大家就可以方便的工作了。当然，如果你是console+editor达人（我是70%的这类达人，:D，hoho），你就可以直接checkout trunk或者branch开发，反正这里也没有什么私人配置文件的问题。

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的时候很麻烦，容易死人。

其实，这里并没有一定之规，更多的时候是两种模式结合使用。我个人来说是采用第一种方式为主，在某些情况下使用第二种方法。
如果你还有其他的好的方法，那么请赐教。:)