迭代开发漩涡，掌控得当能够十分绚丽，如果把控不当就是一个灾难。

问题场景

某互联网公司项目进行迭代式开发，迭代需求较多，出现交叉并行情况很多。随着平台功能的不断增加，偶然的机会出现之前的功能消失了。回想这个功能是某某个迭代版本加入的功能。随着后续迭代版本代码的合并，出现功能回退的现象。

跟踪回溯，在trunk、tag、branch之间查看svn提交记录。记录注释很不全，而且有的描述很粗，不是一般的粗。这对版本追溯带来很大的不便（发现问题没？）。
此公司的迭代版本控制是这样进展的：
首先trunk上维护每个迭代的最新的带都会合入trunk中；tag是针对迭代版本的代码，branch维护迭代分支代码。每次发布迭代tag后，会将tag的代码合入trunk中。

做法

每次迭代分支从trunk中拉出branch，然后进行迭代开发；待迭代版本测试上线时，拉出tag，此tag代码是从最新的trunk中拉出；然后，将branch的代码合入tag中进行测试（发现问题没？）。
这里合并后的代码，缺少了研发的验证过程，直接提测，存在风险。再者，会出新代码冲突问题。此时就需要相关人士进行代码合并。（trunk的版本可能已不是之前拉分支branch时的版本，或许已经是合并n个tag的版本代码）。这里难免出现，合并代码时出现老代码并入，新代码被误删的情况，就像文章开头描述的的问题。之后，测试的tag出人意料的通过了（发现问题没？）。测试缺少回归测试过程。随着迭代的功能越多，这样，回归验证的工作量会不对增加，增加。。。

问题

面对这种迭代功能多，svn版本管理混乱的问题，如何处理，如何减少资源投入？如何保证每次发布的版本功能都是完备的？

建议迭代branch做法

每次tag发布后，合入trunk要知会所有正在开发的branch，然后将最新的trunk合并到对应的开发分支上。每个分支开发完成，从branch打tag提测。测试通过，合入trunk（此时要确保没有新的代码合入trunk中）。如果有，那就重复上述步骤。确保trunk代码和线上最新代码一致，同时提测tag代码 = 线上最新代码+迭代brunch代码。

问题延申

对于线上问题bug修改后，需要紧急上修复版本。此时可能还有正在开发的版本，怎么处理？
建议做法：从trunk上拉出brunch，然后修复bug，之后的步骤同上述（迭代branch处理过程）。

另一种做法：如果线上问题不紧急，可以考虑在正在开发的branch上修复。
不足之处：
这样下来，branch和tag数量会很多。无论是迭代开发brunch还是线上bug修复。

思考不深，愿借鉴之~