任何人都可以推荐在将敏捷与 SVN 一起使用时降低合并成本/复杂性的工作流/使用模式吗？
我知道 use-git 是一个答案，但我正在尝试弄清楚如何在将新工具投入混合之前明智地解决我的问题，因为我目前没有处理中断的周期.
我们最近从具有维护和稳定分支的不稳定主干模型切换到具有功能分支的稳定主干。我们有带有旧维护分支的主干，用于维持和新的团队分支，其中包含功能分支。
团队开发功能并将它们推送到团队分支，然后推送到主干。有时特征也会在特征分支之间合并。我们遇到了树冲突的一些问题(特别是当一个变更集被推送到主干和另一个功能分支时)。
当我们需要将更改转移到维护分支或将更改从它们拉到主干时，这是非常困难的。后备箱和维护已经漂移了很多。
合并妨碍了我们，我正在尝试确定是否存在某些流程问题，我们正在与 SVN 的纹理相悖并导致问题。我正在寻找一种可以减少工作量的更好的分支管理策略。
谁能推荐好的文章、策略或工具？
我会推荐:
使您的功能分支与主干保持同步。将此作为一项常规任务，如果您每隔几天进行一次，则根本不需要时间。当您准备好将工作放到后备箱时，请确保为其提供健康剂量的 QA 并使用 重新整合 合并。 Reintegrate 询问文件和文件夹上的 svn:mergeinfo 属性，以确保从主干同步到您的功能分支的更改不会同步回(“循环”合并)。 确保你只从树干分支，不要从其他分支“级联”分支。我们遇到过这样的情况，即当文件合并回来时，重命名文件上的 COPY-TO 属性没有被跟踪。这可能会导致 SVN 无法正确删除内容，如果您有级联分支，这个问题就会更加复杂。 过去我们在使用 svn:mergeinfo 时遇到了重大问题:首次引入时系统中存在错误，最终将 mergeinfo 放在几乎每个文件和文件夹中。这对我们合并时弊大于利，它只是让自己感到困惑，因此我们决定清除存储库根文件夹之外的每个文件和文件夹上的合并信息。这可以作为分支事件的一个很好的总结。如果您这样做，您将无法获得 SVN 跟踪文件夹/文件移动的所有功能，但是我们遇到了很多问题，最终只能在必要时更快地手动解决树冲突。注意:这个政策是有争议的。除非您确实需要，否则我不建议这样做，但它对我们来说效果很好。 谈到文件夹/文件移动，不要疯狂地重组你的代码库。仅在确实有必要并且确保将更改传达给团队时才移动文件和文件夹。 重命名也是如此，不要无故重命名。存储库中的文件名区分大小写，但 Windows 文件不区分大小写。因此，如果您将文件从“foo.txt”更改为“Foo.txt”，然后再更改回“foo.txt”，则在合并期间 SVN 将尝试删除、添加和重新添加文件。它认为这是不同的，但文件系统会提示，它会退出合并。这些都是非常令人沮丧的案例。 继 Sander Rijken 的评论之后:除了确保您没有进行本地修改外，确保定期删除任何未修订的文件也是一种很好的做法。如果您有一个文件 float ，合并尝试写入 SVN 可能会混淆。对于这种情况，我们有一些 Ruby 内务管理脚本。 注意树冲突。如果您以小剂量合并，它们很容易解决。您只需要在要合并的代码行上查看文件更改的历史记录，然后手动将它们重新应用到目的地。这是最坏的情况，但如果您有负责合并的正确人员，例如对该项目的领导了解工作，然后可以相对较快地解决问题。 最后，确保您的 SVN 客户端保持最新。 哦，是的，拥有一个好的合并工具可以使整个过程减少很多痛苦。我使用 Araxis，但我听说 SmartSVN 中的合并工具也很好。