迭代开发：
　　在软件开发生命周期中，迭代开发模式是基于把一个大的开发周期分解为合理的小的开发周期，小的开发周期的划分可分为：
　　1，按照功能的需求划分为不通 的小的开发周期
　　2，按照交付的需求先后顺序 划分为不通的小的开发周期。
　　前者 笔者认为适合产品的研发划分，比如开发一个产品。
　　后者适合为客户开发项目来划分，比如为某银行开发一套系统。
　　在这样的开发模式下，配置管理的合理规划可以很方便的让开发人员，配置人员，项目经理，测试人员有序的组织工作。
　　怎样合理的规划配置项呢？
　　笔者在这里假设一个工作场景。
　　公司的配置管理基于svn，为某银行开发一套内部系统。该系统大致有30个需求。
　　按照这30个需求的功能已经交付的优先级，拆分为5个小项目，定义为
　　FFR_1.
　　FFR_2
　　FFR_3
　　FFR_4
　　FFR_5
　　其中，交付序列为 1，2，3，4，5 来划分。
　　准备 测试环境，UAT环境，以及客户的生产环境。
　　SVN的规划，我们可以定义为：
　　FFR
　　Branches
　　BR_FFR_2
　　BR_FFR_3
　　BR_FFR_4
　　BR_FFR_5
　　Tags
　　Trunk
　　看到这里，大家觉得奇怪，FFR_1的代码呢？ 因为 FFR_1的代码 我们是需要先交付的，所以 FFR_1的代码， 我们 存放到 trunk 下面。
　　在开发活动中， 我们的开发人员按照开发计划，首先完成FFR_1阶段的开发，所有的提交都在 trunk 下面进行，当 FFR_1 的代码开发完成以后，配置管理员可以对trunk define tag 到 Tags 目录，假定为Rel_FFR_1_1.0.0b1
　　Branches
　　BR_FFR_2
　　BR_FFR_3
　　BR_FFR_4
　　BR_FFR_5
　　Tags
　　Rel_FFR_1_1.0.0b1
　　Trunk
　　Define Rel_FFR_1_1.0.0b1   后，再把Rel_FFR_1_1.0.0b1  部署到测试环境，测试人员开始在上面测试。
　　同时，配置管理员 基于Rel_FFR_1_1.0.0b1   把代码 copy 到 BR_FFR_2 的目录下面，开发人员开始在这段时间，进行 FFR_2 的需求的开发工作，相关的FFR_2的代码提交到 branches 的BR_FFR_2下。
　　在这个过程中， 测试人员在测试环境上发现了Rel_FFR_1_1.0.0b1   版本的 bug， 开发人员回到 trunk上基于Rel_FFR_1_1.0.0b1   发现的bug进行修复。这个过程结束后，配置管理员再基于新的修改 对trunk define tag 到tags 目录 ，假定为Rel_FFR_1_1.0.0b2
　　Branches
　　BR_FFR_2
　　BR_FFR_3
　　BR_FFR_4
　　BR_FFR_5
　　Tags
　　Rel_FFR_1_1.0.0b1
　　Rel_FFR_1_1.0.0b2
　　Trunk
　　Define Rel_FFR_1_1.0.0b2  后，再把Rel_FFR_1_1.0.0b2  部署到测试环境，测试人员开始在上面进行新一轮测试。 开发人员这个时候继续回到branches下的BR_FFR_2目录进行开发工作。
　　假定经过新一轮测试后，测试人员没有在测试环境上发现bug，这个时候，按照计划，我们可以把Rel_FFR_1_1.0.0b2 部署到 UAT环境 进行验收测试。
　　在这个时候，开发人员需要对branches  中BR_FFR_2 代码 merge 到 trunk，然后回到 trunk 上，继续基于FFR_2的需求进行开发。 同时，配置管理人员将 BR_FFR_2 分支 关闭。
　　Branches
　　BR_FFR_3
　　BR_FFR_4
　　BR_FFR_5
　　Tags
　　Rel_FFR_1_1.0.0b1
　　Rel_FFR_1_1.0.0b2
　　Trunk
　　当 FFR_2的需求开发完成以后，配置管理人员再对 trunk define tag 到 tags 目录，假定为
　　REL_FFR_2_1.0.0b1
　　Branches
　　BR_FFR_3
　　BR_FFR_4
　　BR_FFR_5
　　Tags
　　Rel_FFR_1_1.0.0b1
　　Rel_FFR_1_1.0.0b2
　　Rel_FFR_2_1.0.0b1
　　Trunk
　　Define Rel_FFR_2_1.0.0b1   后，再把Rel_FFR_2_1.0.0b1  部署到测试环境，测试人员开始在上面测试。
　　同时，配置管理员 基于Rel_FFR_2_1.0.0b1   把代码 copy 到 BR_FFR_3 的目录下面，开发人员开始在这段时间，进行 FFR_3 的需求的开发工作，相关的FFR_3的代码提交到 branches 的BR_FFR_3下。
　　假定在这个过程中，  客户在UAT 环境发现了基于Rel_FFR_1_1.0.0b2 的bug， 这个时候，配置管理员需要对 tags的Rel_FFR_1_1.0.0b2  建立 braches，来维护Rel_FFR_1_1.0.0b2 的bug 修复
　　Branches
　　BR_FFR_3
　　BR_FFR_4
　　BR_FFR_5
　　BR_ Rel_FFR_1_1.0.0b2
　　Tags
　　Rel_FFR_1_1.0.0b1
　　Rel_FFR_1_1.0.0b2
　　Rel_FFR_2_1.0.0b1
　　Trunk
　　所有的基于Rel_FFR_1_1.0.0b2 的开发将提交到 branches 下的BR_ Rel_FFR_1_1.0.0b2。 当修改完成后，对BR_ Rel_FFR_1_1.0.0b2 define tag 到 tags 目录，假定为   Rel_FFR_1_1.0.0b3