反向合并和svn：mergeinfo

Question

我们正在使用SVN来管理开发管道，我们将开发环境第一阶段的变更合并到第二阶段分支。我们已经创建了将第一阶段的修订合并到第二阶段的工具。

我们要做的是提醒使用此工具的用户如果对第一阶段中工具正在移动的修订影响的文件进行了先前的修订，以便他们审查潜力逻辑依赖关系（无论这些依赖关系是否会导致合并冲突），并确定是否还应将这些先前的修订版移入第二阶段分支。

但是，我们遇到了一个问题，即反向合并的修订版本显示为误报。这是方案

• Alice将修订版100提交到第1阶段的文件。
• Alice意识到他们犯了一个巨大的错误并反向合并r100来为同一个文件创建r101。
• Bob将新的更改r102编码为同一文件。
• Carl已准备好测试Bob的变化，并希望将其拉入第二阶段。他被警告说修订版100和101会影响同一个程序，因此应该检查逻辑依赖项。

根据mergeinfo上的SVN红皮书部分：

  

将反向合并应用于目标的自然历史

     

本章前面（“撤消更改”一节）我们讨论了如何使用svn merge来应用“反向补丁”作为回滚更改的方法。如果使用此技术撤消对对象的个人历史记录的更改（例如，将r5提交到主干，则立即使用svn merge . -c -5回滚r5），这种合并不会导致＃39} ; t影响记录的mergeinfo 。

有没有办法告诉101在我们的场景中是100的反向合并，因此不会将它呈现给我们工具的用户？我们可能会运行一个svn diff，但这似乎有很多开销 - 我们希望使用mergeinfo，但这似乎是不可能的。

有什么想法吗？

Answer 1

我们有以下策略，纯恢复（svn merge -c -<rev>）的提交消息必须以＆＃34; Reverted：＆＃34;开头。我们有一个相当严格的提交消息模板和commit hooks测试（如果你的提交消息不符合，你的提交被拒绝）。当然，这需要纪律......

您始终可以从svn:mergeinfo属性（svn pe svn:mergeinfo）中删除还原。但这仍然需要有人做额外的工作。我们已经为此设置了构建管理器。

第三，您可以将SVN提交与票证系统相结合。在我们的案例中，票证必须达到某种状态才能合并。故障单的所有提交都记录在故障单系统中。我们有一些脚本收集故障单的所有提交并批量合并它们。这允许基于任务的工作方式。

您应该选择适合您的开发过程的东西。并编写一些工具（如有必要）以支持该过程。 Subversion非常灵活，我们使用了一些脚本来管理它。我们甚至有脚本可以在故障单/修订版之间生成依赖关系图（graphviz）。

我希望这会给出一些想法。很抱歉没有出示银弹。

Answer 2

我进一步考虑了这个问题，整个前提似乎有缺陷;我们最初的想法是从mergeinfo 返回的符合条件的修订列表中放弃原始修订和后续反向合并修订，但无法保证后续修订（反向合并已完成） ）包含仅反向合并 - 它可能包含对文件的其他编辑/更改，在这种情况下，它绝对需要应用于分支以避免在挑选其他修订时出现问题。感谢大家的回答。