反向合并和 svn:mergeinfo
Reverse Merge and svn:mergeinfo
我们正在使用 SVN 来管理开发管道，其中我们将开发环境第一阶段的更改合并到第二阶段分支。我们已经创建了将第一阶段的修订合并到第二阶段的工具。
我们想要做的是当第一阶段工具移动的修订影响的文件有先前的修订但第二阶段不存在时提醒使用此工具的用户，以便他们检查潜在的逻辑依赖关系（不管它们是否会导致合并冲突），并确定这些先前的修订是否也应移至第二阶段分支。
但是，我们 运行 遇到了一个问题，即反向合并的修订显示为误报。这是场景
- Alice 将文件的修订版 100 提交到阶段 1。
- Alice 意识到他们犯了一个大错误，并反向合并 r100 为同一文件创建 r101。
- Bob 将新更改 r102 编码到同一文件。
- Carl 准备测试 Bob 的更改并希望将其拉入第二阶段。他被提醒修订版 100 和 101 影响同一个程序，应该检查逻辑依赖性。
根据 mergeinfo 上的 SVN 红皮书部分：
Applying reverse merges to a target's natural history
Earlier in this chapter (the section called “Undoing Changes”) we discussed how to use svn merge to apply a “reverse patch” as a way of rolling back changes. If this technique is used to undo a change to an object's personal history (e.g., commit r5 to the trunk, then immediately roll back r5 using svn merge . -c -5), this sort of merge doesn't affect the recorded mergeinfo.
在我们的场景中，有什么方法可以判断 101 是 100 的反向合并，因此不会将其呈现给我们工具的用户？我们可能 运行 一个 svn diff，但这似乎有很多开销 - 我们希望使用 mergeinfo，但这似乎是不可能的。
有什么想法吗？
我们有以下政策，纯还原 (svn merge -c -<rev>) 的提交消息必须以 "Reverted: " 开头。我们有一个相当严格的提交消息模板和提交钩子测试（如果您的提交消息不符合，您的提交将被拒绝）。当然，这需要纪律...
您始终可以从 svn:mergeinfo 属性 (svn pe svn:mergeinfo) 中删除还原。但这仍然需要有人做额外的工作。我们已经为 构建经理 分配了这个任务。
第三，您可以将您的 SVN 提交耦合到票证系统。在我们的例子中，工单必须在合并之前达到某个状态。票证的所有提交都记录在票证系统中。我们有一些脚本可以收集票证的所有提交并批量合并它们。这允许基于任务的工作方式。
您应该选择适合您的开发过程的东西。并编写一些工具（如有必要）来支持该过程。 Subversion 非常灵活，我们使用了一些脚本来管理它。我们甚至有在 tickets/revisions.
之间生成依赖关系图（graphviz）的脚本
我希望这能提供一些想法。很抱歉没有展示银弹。
我进一步考虑了这一点，整个前提似乎有缺陷；我们最初的想法是从 mergeinfo 返回的合格修订列表中丢弃原始修订和随后的反向合并修订 但是 不能保证后续修订（其中反向合并已完成）包含 仅 反向合并 - 它很可能包含额外的 edits/changes 文件，在这种情况下，绝对需要将其应用于分支以避免出现问题在樱桃采摘其他修订。感谢大家的回答。
我们正在使用 SVN 来管理开发管道，其中我们将开发环境第一阶段的更改合并到第二阶段分支。我们已经创建了将第一阶段的修订合并到第二阶段的工具。
我们想要做的是当第一阶段工具移动的修订影响的文件有先前的修订但第二阶段不存在时提醒使用此工具的用户，以便他们检查潜在的逻辑依赖关系（不管它们是否会导致合并冲突），并确定这些先前的修订是否也应移至第二阶段分支。
但是，我们 运行 遇到了一个问题，即反向合并的修订显示为误报。这是场景
- Alice 将文件的修订版 100 提交到阶段 1。
- Alice 意识到他们犯了一个大错误，并反向合并 r100 为同一文件创建 r101。
- Bob 将新更改 r102 编码到同一文件。
- Carl 准备测试 Bob 的更改并希望将其拉入第二阶段。他被提醒修订版 100 和 101 影响同一个程序，应该检查逻辑依赖性。
根据 mergeinfo 上的 SVN 红皮书部分：
Applying reverse merges to a target's natural history
Earlier in this chapter (the section called “Undoing Changes”) we discussed how to use svn merge to apply a “reverse patch” as a way of rolling back changes. If this technique is used to undo a change to an object's personal history (e.g., commit r5 to the trunk, then immediately roll back r5 using
svn merge . -c -5), this sort of merge doesn't affect the recorded mergeinfo.
在我们的场景中，有什么方法可以判断 101 是 100 的反向合并，因此不会将其呈现给我们工具的用户？我们可能 运行 一个 svn diff，但这似乎有很多开销 - 我们希望使用 mergeinfo，但这似乎是不可能的。
有什么想法吗？
我们有以下政策，纯还原 (svn merge -c -<rev>) 的提交消息必须以 "Reverted: " 开头。我们有一个相当严格的提交消息模板和提交钩子测试（如果您的提交消息不符合，您的提交将被拒绝）。当然，这需要纪律...
您始终可以从 svn:mergeinfo 属性 (svn pe svn:mergeinfo) 中删除还原。但这仍然需要有人做额外的工作。我们已经为 构建经理 分配了这个任务。
第三，您可以将您的 SVN 提交耦合到票证系统。在我们的例子中，工单必须在合并之前达到某个状态。票证的所有提交都记录在票证系统中。我们有一些脚本可以收集票证的所有提交并批量合并它们。这允许基于任务的工作方式。
您应该选择适合您的开发过程的东西。并编写一些工具（如有必要）来支持该过程。 Subversion 非常灵活，我们使用了一些脚本来管理它。我们甚至有在 tickets/revisions.
之间生成依赖关系图（graphviz）的脚本
我希望这能提供一些想法。很抱歉没有展示银弹。
我进一步考虑了这一点，整个前提似乎有缺陷；我们最初的想法是从 mergeinfo 返回的合格修订列表中丢弃原始修订和随后的反向合并修订 但是 不能保证后续修订（其中反向合并已完成）包含 仅 反向合并 - 它很可能包含额外的 edits/changes 文件，在这种情况下，绝对需要将其应用于分支以避免出现问题在樱桃采摘其他修订。感谢大家的回答。