在SVN中限制功能分支合并成本的好方法

Question

在使用敏捷和SVN时，有没有人能推荐一些工作流/使用模式来降低合并的成本/复杂性？

我知道use-git是一个解决方案，但在将一个新工具加入其中之前，我正在尝试找出如何在进程方面解决问题，因为我目前没有处理中断的周期。

我们最近从具有维护和稳定分支的不稳定主干模型切换到具有特征分支的稳定主干。我们有用于维护的旧维护分支的主干，以及具有功能分支的较新的团队分支。

团队开发特性并将其推送到团队分支，然后再推到主干。有时，特征也会在特征分支之间合并。我们会遇到一些树冲突的问题(特别是当变更集同时被推送到主干和另一个功能分支时)。

当我们需要将更改转移到持续维护分支或将更改从它们拉到主干时，这是非常困难的。后备箱和维护已经漂移了相当多。

合并正在阻碍我们，我正在尝试确定是否存在一些流程问题，我们正在削减SVN的颗粒并导致问题。我正在寻找一种更好的分支管理策略，以减少工作量。

有没有人能推荐好的文章、策略或工具？

Answer 1

我会推荐：

• 使您的功能分支与干线保持同步。把这变成一项常规的任务，如果你每隔几天就做一次，那么它根本不需要时间。当您准备将工作放到主干上时，请确保为其提供了健康剂量的QA，并使用reintegrate merge。重新集成询问文件和文件夹上的svn:mergeinfo属性，以确保从主干同步到功能分支的更改不会重新同步下来('cyclic‘merges).
• Ensure你只从主干分支，不要从其他分支’级联‘分支。我们曾经遇到过这样的情况，重命名文件的COPY-TO属性在文件重新合并时没有被跟踪。这可能会导致SVN无法正确删除内容，如果你有级联分支，这个问题会变得更加复杂。
• 在过去，我们对svn有很大的问题:合并信息:当它第一次引入时，系统中有bug，最后它几乎把合并信息放在几乎每个文件和文件夹上。这在合并时弊大于利，它只是把自己搞糊涂了，所以我们决定清除存储库根文件夹之外的每个文件和文件夹上的mergeinfo。这可以作为分支活动的一个很好的总结。如果你这样做，你不会得到SVN跟踪文件夹/文件移动的所有功能，但我们有太多的问题，结果只是在必要的地方更快地手动解决了树冲突。注意:这个政策是有争议的。我不建议这样做，除非您真的需要这样做，但它对我们来说效果很好。
• 谈到文件夹/文件移动，不要疯狂地重组你的代码库。只有在确实有必要的时候才移动文件和文件夹，如果你确实确保将更改传达给你的团队。
• 重命名也是如此，没有充分的理由就不要重命名。存储库中的文件名区分大小写，但Windows文件不区分大小写。因此，如果您将文件从'foo.txt‘更改为'foo.txt'，然后再更改回'Foo.txt’，则在合并过程中，SVN将尝试删除、添加，然后重新添加该文件。它认为它是不同的，但文件系统会抱怨，它会跳出合并。从Sander Rijken的评论中，这些是非常令人沮丧的cases.
• Following on :除了确保你没有本地修改，这也是一个很好的实践，确保你定期删除任何未修改的文件。如果您有一个浮动的文件，合并试图覆盖它，那么SVN可能会被混淆。对于这种情况，我们有一些Ruby的内务脚本，
• 会注意树的冲突。如果您以小剂量合并，则很容易解决这些问题。您只需在您要合并的代码行上查看文件更改的历史记录，并手动将其重新应用于目标。这是最坏的情况，但如果你有正确的人负责合并，例如，该项目的领导了解工作，那么他们可以相对地解决，确保你的quickly.
• Finally，客户端保持最新。
• 哦，是的，有一个好的合并工具可以让整个过程变得更轻松。我用的是Araxis，但我听说SmartSVN中的合并工具也不错。

Answer 2

我能想到的一些事情可以帮助减少可能的冲突：

通过在工作副本的根目录上运行svn up，确保您的工作副本处于单一版本。

• 确保您没有本地稀疏工作副本确保没有切换的子项(当您切换wc内的目录而不是wc本身时会发生这种情况)
• 确保使用depth=infinity签出工作副本，即无稀疏工作副本

Answer 3

根据某些功能的独立程度，您可以考虑制作功能模块，并将其包含在svn:externals中(可能会固定某个版本)。这取决于代码库/项目是否适合这种模块化。