【问题标题】:Reverse Merge and svn:mergeinfo反向合并和 svn:mergeinfo
【发布时间】: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


【解决方案1】:

我们有以下政策,纯还原 (svn merge -c -<rev>) 的提交消息必须以“Reverted:”开头。我们有一个相当严格的提交消息模板和提交钩子测试(如果你的提交消息不符合,你的提交被拒绝)。当然,这需要纪律...

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

第三,您可以将 SVN 提交与票证系统结合起来。在我们的例子中,票证必须在合并之前达到某个状态。工单的所有提交都记录在工单系统中。我们有一些脚本可以收集票证的所有提交并将它们批量合并。这允许基于任务的工作方式。

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

我希望这能提供一些想法。很抱歉没有展示灵丹妙药。

【讨论】:

  • 我很欣赏这些建议,但想澄清一下,当前正在恢复的修订不在 svn:mergeinfo 中 - 我想如果我们合并了原始版本,它们将在下游分支的 mergeinfo 中向下游提交,在这种情况下,我们还希望合并还原。我们正在使用票务系统和工具,因此我们可以了解被还原的更改的状态,但我惊讶地发现这里没有来自 SVN 的帮助——这似乎不是一个令人发指的用例来跟踪提交被反向合并。
  • 跟踪要集成的修订的最简单方法是让两个开发流成为彼此的分支,并使用svn:mergeinfo 跟踪正在合并的修订。 SVN 对分支和合并的理解很差,这使得它特别适合 cherry pick(合并单个修订)。 (类似于打补丁。)在第二阶段分支中,使用svn mergeinfo --showrevs eligible <URL to first stage branch>检查未合并的修订,svn merge -c <rev> <URL to first stage branch>合并所述修订。
  • 是的,这就是我们所做的——我提出的问题是,在挑选后续修订时,已反向合并的修订将始终显示为要合并的合格修订,并且没有办法第二阶段要知道哪个版本是原始版本,哪个版本是该文件的多个版本之间的反向合并,因此无法自动合并两者以实现无操作。
【解决方案2】:

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

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2010-12-28
    • 2011-06-05
    • 2014-04-17
    • 2015-12-20
    • 2022-11-28
    • 2018-11-29
    • 2011-04-03
    • 1970-01-01
    相关资源
    最近更新 更多