反向合并和svn:mergeinfo

Question

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

我们要做的是提醒用户使用此工具，当在第一阶段对受修订影响的文件进行先前的修订时，该工具在第二阶段中并不存在，以便他们检查潜在的逻辑依赖(不管这些是否导致合并冲突)，并确定这些先前的修订是否也应该移动到第二阶段分支中。

然而，我们遇到了一个问题，即反向合并的修订结果显示为假阳性。这里是一个场景

• Alice将修订版100提交到第1阶段的文件。
• Alice意识到他们犯了一个巨大的错误，并反向合并r100为同一个文件创建了r101。
• Bob将一个新的更改r102编码到同一个文件。
• 卡尔已经准备好测试鲍勃的变化，并想把它拉到第二阶段。他被告知，修订100和101影响相同的程序，并应审查逻辑依赖。

根据mergeinfo上的SVN红皮书部分

将反向合并应用于目标的自然历史 在本章的前面(称为“撤消更改”一节)中，我们讨论了如何使用svn合并应用“反向修补程序”作为回滚更改的一种方法。如果该技术用于撤消对对象个人历史记录的更改(例如，将r5提交到主干，然后立即使用svn merge . -c -5回滚r5 )，则这种合并不会影响记录的合并信息。

在我们的场景中，有任何方法可以判断101是100的反向合并，因此不会将其呈现给工具的用户吗？我们可能会运行svn，但这似乎需要大量的开销--我们希望使用mergeinfo，但这似乎是不可能的。

有什么想法吗？

Answer 1

我对此作了进一步的思考，整个前提似乎存在缺陷；我们最初的想法是从mergeinfo 返回的合格修订列表中删除原始版本和随后的反向合并版本，但是不能保证随后的修订版(其中进行了反向合并)只包含反向合并--它很可能包含文件的额外编辑/更改，在这种情况下，它绝对需要应用到分支部门，以避免在选择其他版本时出现问题。感谢你的回答。

Answer 2

我们有以下策略，纯还原(svn merge -c -<rev>)的提交消息必须以"Reverted：“开头。我们有一个相当严格的提交消息模板，并为此进行了提交挂钩测试(如果提交消息不符合，则提交将被拒绝)。当然，这需要纪律..。

您可以始终从svn:mergeinfo属性(svn pe svn:mergeinfo)中删除还原。但这仍然需要有人做额外的工作。我们已经指派了一个构建经理来完成这个任务。

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

您应该选择适合您的开发过程的东西。并编写一些工具(如果必要的话)来支持这个过程。Subversion非常灵活，我们使用了一些脚本来管理这个问题。我们甚至有在票据/修订版之间生成依赖关系图(用graphviz)的脚本。

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