【发布时间】:2015-06-10 13:53:00
【问题描述】:
我们使用 SVN 来管理开发管道,其中我们将开发环境第一阶段的更改合并到第二阶段分支中。我们创建了将第一阶段的修订合并到第二阶段的工具。
我们想要做的是提醒使用此工具的用户,当该工具在第一阶段移动的修订影响的文件的先前修订在第二阶段不存在时,以便他们审查潜在的逻辑依赖关系(无论这些是否导致合并冲突),并确定这些先前的修订是否也应移至第二阶段分支。
但是,我们遇到了一个问题,即反向合并的修订显示为误报。这是场景
- Alice 将修订版 100 提交到第 1 阶段的文件。
- Alice 意识到他们犯了一个巨大的错误,并反向合并 r100 以为同一文件创建 r101。
- Bob 将新的更改 r102 编码到同一文件中。
- Carl 已准备好测试 Bob 的更改并希望将其拉入第二阶段。他会收到警告,修订版 100 和 101 会影响同一个程序,因此应审查其逻辑依赖性。
根据mergeinfo上的SVN红皮书部分:
对目标的自然历史应用反向合并
在本章前面(称为“撤消更改”的部分)中,我们讨论了如何使用 svn merge 应用“反向补丁”作为回滚更改的一种方式。如果此技术用于撤消对对象个人历史的更改(例如,将 r5 提交到主干,然后立即使用
svn merge . -c -5回滚 r5),这种合并不会影响记录的合并信息 em>。
在我们的场景中,有什么方法可以判断 101 是 100 的反向合并,因此不会将其呈现给我们工具的用户?我们可能会运行 svn diff,但这似乎有很多开销 - 我们希望使用 mergeinfo,但这似乎是不可能的。
有什么想法吗?
【问题讨论】:
-
我们遇到了类似的问题,我们能做的最好的事情就是使用我们类似的工具来合并修订以创建可解析的日志消息并将该信息包含在其中。不漂亮,但它可以满足我们的需要。
标签: svn version-control merge