我对SVN的理解
SVN是一种软件开发中非常流行的源代码版本控制工具软件，它能保存你每一次的源代码提交历史，便于我们对源码的历史做追溯，这样的好处是：
- 可以浏览软件源代码版本的演化历史以及回滚相关历史版本代码
- 分支系统优秀，可以多人进行协作开发
- 管理方便，逻辑明确，符合一般人思维习惯。
- 易于管理，集中式服务器更能保证代码安全性。
- 代码一致性非常高。
SVN适合开发人数不多的项目开发。大部分软件配置管理的大学教材都是使用SVN系统。
其中SVN的分支功能可以说是SVN源代码控制系统的核心功能。根据trunk分支的功用不同我将分支的使用方式分为两类：
- 以trunk作为稳定发布分支(Basically stable)
- 以trunk作为开发分支(Basically unstable)
以trunk作为稳定发布分支
顾名思义这个分支原则主导思想是trunk只包含稳定的随时可发布的代码。branches则用于开发新功能/修正bug/发布前的QA控制/重构/实验性质功能试点。一切未经测试验证的代码都禁止向trunk提交。
这个是我从参加工作以来历届公司的开发方式，什么是以trunk作为稳定发布分支？这里我们从第一份的源代码说起，第一份源代码我们提交到SVN上的trunk上，并进行开发，开发完结后我们发布第一个版本，我们称之为第一个稳定版本，在第一个稳定版本完成后，以后所有的开发都不会在trunk上进行提交，什么意思呢？假如这时有一个新需求到来，那么就从主干trunk上提取一份代码（术语叫分支）到另一分支目录（一般分支目录取名branches），建立自己的开发分支，测试也是在分支上完成功能测试。待要发布时才将分支代码合并到主干上。因为主干trunk上的代码从一开始到每次迭代都是非常稳定的，所以这种方式叫以trunk为稳定发布分支的开发方式。每当开发完成某项功能，并达到发布标准且分支源代码已经合并到trunk分支后，我们就会以当前的trunk打出一个标签(tag)，标识一个稳定的版本（里程碑）。
这种开发方式的优点是：
- trunk代码非常稳定，始终存在一个功能稳定的分支可用
- 代码开发的并行度非常高
- 代码之间的抗干扰非常强
缺点是：
- 可能会存在较多分支（一般以某个功能或某几个功能作为一个功能分支开发）
- 代码发布前需要合并到trunk，可能会产生代码冲突，需要人工合并
目前大部分的互联网公司的源代码分支开发方式都是采用的这种方式。
以trunk作为开发分支
Basically unstable原则下，要求trunk包含最新的代码，不管它的稳定性如何；
而用于release candidate的版本则应该开辟一个分支来交付。
这种开发方式是我现在这家公司的团队所使用的源代码管理方式（现因为这种方式的缺点已经转向Basically stable模式），与上面的方式不同的是，所有的开发源代码提交都是直接在trunk上提交，即trunk上拥有最新的项目功能代码，也就是说trunk上不断会有人提交代码，也可以说trunk上的代码是非常不稳定的。所有的测试人员都是基于trunk进行代码测试，当测试完毕后，由trunk上打出一个发布tag。当然在我看来这种方式存在的问题很大，这种开发方式的优点我想了想可能只有以下一条：
- 所有人基于同一分支开发代码，测试代码，发布代码，基本不存在合并冲突的风险
但是这种开发方式的缺点我却可以随便列举两个：
-
trunk代码非常不稳定，源代码中不容易找出当前的稳定版本分支
什么意思呢？就是说所有的人都在不断的向trunk分支上提交代码，这个分支的测试是相当困难的，根据测试的相关原理，如果在已经测试OK的代码基础上提交代码，理论上说可能存在污染原已经测试过的代码，增加了引入新BUG的风险程度 -
代码开发的并行度极低
为什么说并行度极低呢？比如说两个开发人员需要完成不同需求，他们都在trunk上开发，这样会导致的一个问题是可能A开发人员已经开发好了一个功能，但是B开发人员还没有完成相关的功能需求，那么此时A是无法进行上线上操作的，或者说可能会遇到代码残缺甚至无法启动的问题。那么此时A开发人员只能是等到B开发人员完成相关功能后才能发布，且B开发人员开发的相关功能更改可能会对A的功能造成影响。
目前许多开源的软件会采用这种开发方式。
我觉得：
-
如果是开发开源软件，那么可以考虑使用以trunk作为开发分支的方式，原因如下：
开源软件有着良好的人员素质以及里程碑控制，开源软件的发布毕竟来说不会是非常频繁的，它们有着自己的roadmap（路线图），所有的开发人员都是以这种roadmap作为开发主线，即在某一里程碑完成前所有人都是可以向trunk上提交代码的，但是一旦代码功能完成，进行测试期间时，trunk分支已经被冻结的，所有的人员都不能够向trunk提交代码。这样避免了我上面所说的测试代码污染性的问题。当软件测试完成并需要发布一个版本时，会从trunk上打出一个tag(标签)。作为后续软件特有版本BUG修复的源代码基线。这也是大家浏览开源软件的源代码仓库时看到的情景。开源的软件，或者说是基于版本发布的软件，它们更需要对发布版本的控制，因为它们需要对每个发布版本都维持有相关的修复生命周期，在该软件的某个版本发现的BUG，需要针对该版本（tag）进行修复，并合并回trunk以修复最新发布的版本。 -
如果是互联网公司的软件开发，并且所开发的软件是以服务方式（网站、API、WS、网络基础服务等）提供给外部用户使用，那么请考虑使用以trunk作为稳定发布分支的方式，原因如下：
互联网公司的开发节奏是非常快的，虽然它也可能存在里程碑式的管理，但是这里面存在的发布与上线的次数是远远大于开源软件的版本发布，那么这里存在的问题就是，如何快速的实现功能迭代上线，这要求软件开发过程中的并行度要非常高且相互不受影响。而且由于是以服务的方式提供，所以不存在历史版本的维护问题，即源代码是不断向前演进的，并不需要对某个版本的服务需要进行BUG修复，所有的修复工作都是在服务端的自然演进中完成修复工作。
