Question

SVN开多个分支，不同的分支修改项目中不同模块的BUG（也可在不同模块中新增功能）

同上，公司想用SVN进行版本控制，开多个分支，每个分支都有负责不同模块的开发人员修改BUG，或是新增功能，测试通过后，将多个分支修改后的内容合并到主干上（可能会涉及到不同分支下，同一个文件的修改，会发生冲突），合并完成后，测试通过的话，就可发版。由于这样合并，导致主干与分支的内容不一致，所以，需要再次把主干的内容合并到每个分支上，这样继续开发才不会有问题。SVN这样操作可行么？容易产生什么后果？（多个分支合并到主干，再从主干合并到多个分支）

Answer 1

1、可以操作。
2、前提你是要熟悉SVN的分支的原理。只下载主线目录（通过TSVN的主线与分支的切换，合并到本地，合并源选对方以及提交选择路径实现），
3、后果的话，因为你是N个分支->主线先合并，主线上拥有了所有分支的特性，然后再主线把其他分支的特性合并到某个分支。相当于所有的分支都是从新的版本出发的。SVN操作上和软件开发上问题不大，主要是这样做不方便分支的管理。
4、第一种SVN开发方式：集中主线开发，分支辅助实现（软件变体、交迭、缺陷修复、隔离试探、多层集成、第三方源码），然后合并到主线，然后关掉分支。
5、你这种SVN开发方式是第二种，trunk上实现 集成、构建、测试和发布，分支用来开发。最大的问题也就是你说的冲突，因为分支本身是隔离的，分支内部能交流，分支之间无法交流，无法共享代码，容易对项目的理解产生分歧导致无法合并，另外权限控制也是个很严重的问题，可能分支的权限会放的比较开，有些人会修改其他人负责的代码。合并操作的频率非常高，也容易出现合并的逻辑出问题或者忘记了合并，导致主线构建不成功。
6、如果你用第二种方式，做法应该是-：分支开发->分支合并到主线->主线合并到分支->构建->测试->发布->关闭原分支->新的分支 .....。也就是说 只要你发布了版本就应该重新开分支。这样的后果就是分支无法进行下一个版本的新功能的开发。你原有的做法会导致版本在需要发布的时候因为模块进度不同 导致选择需要合并的文件时混乱。

Answer 2

“所以，需要再次把主干的内容合并到每个分支上，这样继续开发才不会有问题。”

你可以从主线当前节点拉出不同分支呀。为什么要把主线合并到各个分支呢？表示不理解