与集中式开发不同的在于，我们branches中存在的是各个开发人员所负责的切片，而主干中则一直是稳定的SNAPSHOT版本——这其实是符合逻辑的，SNAPSHOT代表的意义是预览而不是“破烂”，至少能够正常的运行起来才能算的上是预览版，而集中式开发的主干虽然标注的是SNAPSHOT预览版，实际上其实是一个“破烂”——正常情况下你是运行不起来的，开发环境总是存在各种各样的不确定性。
用语言描述一下开发步骤：在主干trunk中新建一个项目，然后copy to branches，分别建立milestone、sp1、sp2...spN，每一个切片对应一个开发或前端或白盒测试，当大家各自开发完毕之后，提交代码，项目经理将sp1、sp2等切片合并到milestone中，这里注意了，不是合并到trunk中，而是一个分支的名字叫milestone——里程碑，专门用来合并各种代码，milestone的代码进行合并之后，部署到测试环境让测试组介入测试——完毕之后合并到trunk，然后在trunk上进行发布，在tag中归档并上线，trunk中的版本号升级到下一版本，然后所有开发切片重新切片。
上面的描述如果感到拗口的话，可以看这个场景：
项目经理建了一个项目，版本号是1.0.0-SNAPSHOT，程序员小王从项目经理那里领到一个任务是开发订单查询中心这个模块，他的切片是1.0.0-SNAPSHOT-SP1，开发完毕之后提交了代码，项目经理合并代码到milestone上，然后小王开始开发其他的代码，项目经理陆续从小张、小李那边收到SP2、SP3的代码之后，觉得可以发布一版了，叫上测试对milestone进行测试，通过之后合并到主干打tag上线，此时线上版本号是1.0.0-RELEASE，主干上的版本号是 1.1.0-SNAPSHOT，此时项目经理重新切片，所有人的代码从1.0.0-SNAPSHOT-SPn转换到1.1.0-SNAPSHOT-SPn进行开发，milestone同样变成1.1.0-SNAPSHOT，循环往复……
同样存在集中式开发的问题——老版本出现BUG怎么办？我们这里同样模拟一个场景。
1.0.0-SNAPSHOT通过了测试并且已经打tag上线了，线上版本是1.0.0-RELEASE，trunk上的版本号是1.1.0-SNAPSHOT，milestone上的版本也是1.1.0-SNAPSHOT，所有的开发都已经认领了各自的1.1.0-SNAPSHOT的SP进行下一版的开发，此时1.0.0-RELEASE发生了一个隐藏的BUG需要紧急修复并上线，项目经理找到BUG负责人小王，让他对他所负责的1.0.0-SNAPSHOT-SPn进行fix，修补完毕之后依次合并milestone、测试、打tag上线，此时线上版本是1.1.0-RELEASE，主干版本变成1.1.1-SNAPSHOT，milestone同样为1.1.1-SNAPSHOT。
到此，我们产生了一个疑问：因为小王的BUG导致主干版本比开发的SP版本高了一个版本，是不是会有冲突呢？
其实是没有冲突的，SP的版本号其实是弱化了的——实际上我根本不关心SP的版本号是否正确，当发生不正确的情况出现，由各个切片的开发人员自己通过Merge里程碑Milestone的代码解决。
总结一下分散式开发引申出来的几个概念：
SP：开发切片。
MILESTONE：里程碑，对应的是测试环境
TRUNK：主干，对应的是预发布环境
TAG：归档，对应的是线上环境
分散式开发重点解决的是保证测试环境的相对稳定、预发布环境的绝对稳定以及线上环境的绝对稳定问题，并且我们试想一下：是不是能够轻松做到持续交付了呢？
总结集中式开发适合一些小型项目的开发，例如微服务、小组件。
分散式开发适合快速迭代——对于未知的需求贴合的更好。
Ubuntu 14.04 下搭建SVN服务器 SVN://
CentOS 6.2 SVN搭建 (YUM安装)
Windows下SVN服务器搭建和使用 + 客户端重新设置密码