代码之家  ›  专栏  ›  技术社区  ›  radman

SVN支持历史合并,那么Mercurial如何更好呢?[复制品]

  •  4
  • radman  · 技术社区  · 15 年前

    可能重复:
    Merging: hg/git vs. svn

    你好,

    我是一个很长一段时间的SVN用户,我已经听到了很多关于反复无常和分散版本控制系统的问题。我所知道的一个主要的吹捧特性是,在Mercurial中进行合并要容易得多,因为它记录了每次合并的信息,所以每次连续的合并都可以知道之前的合并。

    现在如 red book 在要进行合并的部分中,SVN已经用mergeinfo支持此功能。现在我还没有真正使用这个功能(尽管我想,我们的repo版本还不够新),但是这个SVN功能是否与Mercurial提供的功能特别不同?

    对于不知道SVN中历史合并建议工作流程的任何人来说:

    1. 从开发主干到 做你自己的事。

    2. 定期合并来自主干的更改 到你的分支机构了解最新情况。

    3. 完成后合并回 合并信息以平滑处理过程。

    如果不合并历史数据,这将是一个噩梦,因为比较严格地基于文件的差异,而不考虑在过程中采取的步骤。因此,当您重新合并时,开发主干中的每个更改都会使您进一步陷入可能的冲突中。

    现在我想知道的是:

    与SVN中的mergeinfo相比,使用mercurial进行合并是否提供了显著的优势,或者这仅仅是一堆空话?

    有人在SVN中使用过mergeinfo特性吗?实际上它有多好?

    1 回复  |  直到 15 年前
        1
  •  7
  •   Community CDub    8 年前

    正如评论中所提到的,这个问题大致概括了它,但它指出了确切的颠覆(最新的1.6!)说明合并限制的文档:

        svn merge --reintegrate ^/branches/my-calc-branc
    

    曾经一次 --reintegrate 合并是从分支到主干的,分支不再可用于进一步的工作。它不能正确地吸收新的主干变化,也不能正确地重新融入主干。

    什么?如果自上次合并回主干之后,您在该分支上做了更多的工作,就不能再做第二次了 --重新整合 合并?
    您必须创建另一个分支或使用 a cherry-picking syntax with yet 另一个保持活力的选择。

    结论告诉你你需要知道的一切:

    归根结底,Subversion的合并跟踪功能具有极其复杂的内部实现 svn:mergeinfo 属性是用户进入机器的唯一窗口。由于该功能相对较新,可能会弹出许多边缘情况和可能的意外行为。

    例如,有时在运行简单的 svn copy svn move 命令。

    • 有时,mergeinfo会出现在您不希望被操作触及的文件上。
    • 有时,在您期望的时候,MergeInfo根本不会被生成。

    此外,对mergeinfo元数据的管理还包括:

    • 它周围的一整套分类法和行为,如显式与隐式合并信息,操作与不操作修订,
    • 合并信息消除的具体机制,
    • 甚至是从父目录到子目录的继承。

    让我们将其与DVC进行比较:

    已经合并;)

    这并不意味着SVN不知道如何合并(简单来说 merge workflow 它将完成这项工作),但其底层机制的复杂性将有效地抑制分支和合并的使用,使少数合并变得相当微不足道。
    相比之下,DVC中合并操作的简单性将增加分支的使用量和合并场景的复杂性,这不再是一个问题。