迭代开发：
　　在软件开发生命周期中，迭代开发模式是基于把一个大的开发周期分解为合理的小的开发周期，小的开发周期的划分可分为：
　　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

　　同时将Rel_FFR_1_1.0.0b3 部署到 UAT环境进行新一轮测试。
　　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_1_1.0.0b3
　　Rel_FFR_2_1.0.0b1
　　Trunk
　　在这个点上，trunk 上面的代码主要是FFR_2的开发，分支上的BR_ Rel_FFR_1_1.0.0b2 主要是针对FFR_1的代码修复分支上的BR_FFR_3 主要是是针对FFR_3的开发工作，当Rel_FFR_2_1.0.0b1 在测试环境上发现 bug后，开发人员就回到 trunk 针对基于Rel_FFR_2_1.0.0b1 发现的bug 进行修改。 修改完成后，再针对trunk define tag 到tags 目录，假定Rel_FFR_2_1.0.0b2，然后部署到测试环境进行测试。
　　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_1_1.0.0b3
　　Rel_FFR_2_1.0.0b1
　　Rel_FFR_2_1.0.0b2
　　Trunk
　　当Rel_FFR_1_1.0.0b3 在UAT 上完成测试后，配置管理人员将关闭BR_Rel_FFR_1_1.0.0b2 分支，同时将上面的修改merge到 trunk。
　　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_1_1.0.0b3
　　Rel_FFR_2_1.0.0b1
　　Rel_FFR_2_1.0.0b2
　　Trunk
　　剩下的工作就是对以上步骤的循环，最后完成整个 FFR_1，FFR_2，FFR_3，FFR_4，FFR_5的开发。
　　这个过程是一个 同步迭代的过程。
　　最后，对这个过程有需要完善和修改的地方，欢迎补充。