从 Subversion feature branch requires changes from another feature branch转移而来
我有两个特性分支："FeatureA"和"FeatureB"。 "FeatureA"已完成，但尚未合并到主干，因为尚未确认它是否应该在下一个版本中发布。
"FeatureB"正在进行中，结果发现需要对dbml进行一些更改，这些更改实际上已经应用于"FeatureA"。
我有几个选项之一是仅合并dbml和相关文件。 我知道最佳实践是从工作副本根目录合并/更新/提交等，但如果我继续前进会引起哪些问题？
您可以将FeatureB分支中的所有修订版本合并到您想要的FeatureA分支中（最好记录已合并的修订版本，因为Subversion不会为您执行此操作--svnmerge.py工具会执行此操作，但我宁愿自己记录）。然后撤消/删除您不想要的更改（例如，如您在早期问题中所述，这些更改是修订版本的一部分）。
我想说的是：“稍后，在将FeatureA和FeatureB与主干合并时，如果您撤消的更改与FeatureB分支中的其他更改无关，则不应该出现冲突。” 但我不确定这是否正确。也就是说，如果FeatureA和FeatureB中存在共同的更改，当这些更改合并到主干时，是否会出现冲突/重复更改？
解决方法是采取安全的方法，并自己进行艰难的核算，以便在稍后对主干执行合并时不会重复任何更改。
简化的方法之一是在代码中使用标志来打开或关闭FeatureA。这样，FeatureA就可以与主干合并。
我发现记住 SVN 中合并的三个参数很有用。你需要将将将版本 X 转换为版本 Y 的更改应用于版本 Z。我认为这与您关于使用工作副本的说法相冲突。
因此，一种方法是找到在 Feature A 分支中对 dbml 所做的更改（由起始版本和结束版本确定），并将这些更改应用于 Feature B 分支。
我认为你在涉及“子树合并信息”的问题。专家们说最好避免。但性能也是一个问题，因为在大型分支的根处运行合并可能需要很长时间。为了避免这些性能问题，我已经做了子树合并，并确认生成的子树合并信息确实会引起一些问题。所以尽可能避免使用它。
