合并：汞/ Git与SVN [英] Merging: Hg/Git vs. SVN

问题描述

我经常读到Hg（和Git和...）在合并时比SVN更好，但我从来没有见过Hg / Git可以合并SVN失败的地方（或SVN需要手动干预的地方）的实例。您可以发布分支/修改/提交/ ...操作的几个分步列表，其中显示SVN会在Hg / Git愉快地移动时失败吗？一些背景：我们有几十个开发人员在使用SVN进行项目工作，每个项目（或一组类似的项目）在它自己的存储库中。我们知道如何应用发行版和功能分支，所以我们不会经常遇到问题（即，我们一直在那里，但我们已经学会了克服。我们有非常稳定的发布分支，只用于应用错误修正。我们有足够稳定的中继线，可以在一周内创建发行版。我们拥有单个开发人员或开发人员团队可以使用的功能分支。是的，它们在重新整合后被删除，所以它们不会混淆版本库。 ;）

所以我仍然在试图找出Hg / Git优于SVN的优势。我很乐意获得一些实践经验，但是我们没有任何更大的项目可以转移到Hg / Git，所以我一直坚持使用只包含少量配置文件的小型人造项目。而且我正在寻找一些可以感受到Hg / Git强大功能的案例，因为到目前为止我经常阅读它们，但是没有亲自找到它们。

h2_lin>解决方案

我不使用Subversion，而是从针对Subversion 1.5的发布说明：合并跟踪（基础）看起来与合并跟踪在Git或Mercurial等全DAG版本控制系统中的工作方式有以下不同。

• 合并中继到分支不同于合并分支到中继：由于某些原因合并中继到分支需要 - 重新整合选项到 svn merge 。

  
  
  

  在像Git或Mercurial这样的分布式版本控制系统trunk和branch之间没有技术上的区别：所有分支的创建都是平等的（尽管可能存在 social 差异）。您需要提供新的 -g （

） code> - use-merge-history ）选项 svn log 和 svn blame


在Git和Mercurial中，显示历史记录（日志）和责备时会自动考虑合并跟踪。在Git中，您可以请求仅使用 - first-parent （我猜Mercurial也存在类似的选项）在$ c中放弃合并跟踪信息$ c> git log 。




• 从我理解的 svn：mergeinfo 有关冲突的属性商店每路径信息（Subversion是基于变更集的），而在Git和Mercurial中，它只是提交可以有多个父对象的对象。

Subversion中的已知问题子合并跟踪表明重复/循环/反射合并可能无法正常工作。这意味着在下面的历史中，第二次合并可能不会做正确的事情（'A'可以是主干或分支，'B'可以分别是分支或主干）：



 
 * --- * --- x --- * --- y --- * --- * --- * --- M2 < -  A 
 \\ / 
  -  * ---- M1 --- * --- * --- / < -  B 
 

在上述ASCII艺术被破坏的情况下：分支'B'从修订版'x'处的分支'A'被创建（分叉），然后在分支'A' y'分支'B'合并为'M1'，最后分支'B'合并为'M2'分支'A'。

 
 * --- * --- x --- * ----- M1  -  * --- *  - -M2 < -  A 
 \ / / 
 \\  -   -  * --- y --- * --- * --- / < -  B 
 

在上述ASCII艺术被破坏的情况下：分支'B'在修订版'x'处由分支'A'创建（分叉），它被合并到'y'的分支'A'中作为'M1'，然后再次合并到分支'A'中作为'M2'。 Subversion可能不支持纵横交错的高级案例。

 
 * --- b ----- B1  -  M1  -  * --- M3 
 \\ // 
 \ X / 
 \ / \ / 
 \  -  B2  -  M2  -  * 
 

在实践中，Git处理这种情况很好递归合并策略。 在已知问题中存在警告：合并跟踪大部分不适用于文件重命名，例如当一边重命名文件（也许修改它），第二面修改文件而不重命名（旧名称下）。





Git和Mercurial处理这种情况都很好练习：Git使用重命名检测，使用重命名跟踪的Mercurial。

HTH

I often read that Hg (and Git and...) are better at merging than SVN but I have never seen practical examples of where Hg/Git can merge something where SVN fails (or where SVN needs manual intervention). Could you post a few step-by-step lists of branch/modify/commit/...-operations that show where SVN would fail while Hg/Git happily moves on? Practical, not highly exceptional cases please...

Some background: we have a few dozen developers working on projects using SVN, with each project (or group of similar projects) in its own repository. We know how to apply release- and feature-branches so we don't run into problems very often (i.e., we've been there, but we've learned to overcome Joel's problems of "one programmer causing trauma to the whole team" or "needing six developers for two weeks to reintegrate a branch"). We have release-branches that are very stable and only used to apply bugfixes. We have trunks that should be stable enough to be able to create a release within one week. And we have feature-branches that single developers or groups of developers can work on. Yes, they are deleted after reintegration so they don't clutter up the repository. ;)

So I'm still trying to find the advantages of Hg/Git over SVN. I'd love to get some hands-on experience, but there aren't any bigger projects we could move to Hg/Git yet, so I'm stuck with playing with small artificial projects that only contain a few made up files. And I'm looking for a few cases where you can feel the impressive power of Hg/Git, since so far I have often read about them but failed to find them myself.

解决方案

I do not use Subversion myself, but from the release notes for Subversion 1.5: Merge tracking (foundational) it looks like there are the following differences from how merge tracking work in full-DAG version control systems like Git or Mercurial.

• Merging trunk to branch is different from merging branch to trunk: for some reason merging trunk to branch requires --reintegrate option to svn merge.

  In distributed version control systems like Git or Mercurial there is no technical difference between trunk and branch: all branches are created equal (there might be social difference, though). Merging in either direction is done the same way.

• You need to provide new -g (--use-merge-history) option to svn log and svn blame to take merge tracking into account.

  In Git and Mercurial merge tracking is automatically taken into account when displaying history (log) and blame. In Git you can request to follow first parent only with --first-parent (I guess similar option exists also for Mercurial) to "discard" merge tracking info in git log.

• From what I understand svn:mergeinfo property stores per-path information about conflicts (Subversion is changeset-based), while in Git and Mercurial it is simply commit objects that can have more than one parent.

• "Known Issues" subsection for merge tracking in Subversion suggests that repeated / cyclic / reflective merge might not work properly. It means that with the following histories second merge might not do the right thing ('A' can be trunk or branch, and 'B' can be branch or trunk, respectively):

  *---*---x---*---y---*---*---*---M2        <-- A
           \       \             /
            --*----M1---*---*---/           <-- B
  

  In the case the above ASCII-art gets broken: Branch 'B' is created (forked) from branch 'A' at revision 'x', then later branch 'A' is merged at revision 'y' into branch 'B' as merge 'M1', and finally branch 'B' is merged into branch 'A' as merge 'M2'.

  *---*---x---*-----M1--*---*---M2          <-- A
           \       /           / 
            \-*---y---*---*---/             <-- B
  

  In the case the above ASCII-art gets broken: Branch 'B' is created (forked) from branch 'A' at revision 'x', it is merged into branch 'A' at 'y' as 'M1', and later merged again into branch 'A' as 'M2'.

• Subversion might not support advanced case of criss-cross merge.

  *---b-----B1--M1--*---M3
       \     \ /        /
        \     X        /
         \   / \      /
          \--B2--M2--*
  

  Git handles this situation just fine in practice using "recursive" merge strategy. I am not sure about Mercurial.

• In "Known Issues" there is warning that merge tracking migh not work with file renames, e.g. when one side renames file (and perhaps modifies it), and second side modifies file without renaming (under old name).

  Both Git and Mercurial handle such case just fine in practice: Git using rename detection, Mercurial using rename tracking.

HTH

这篇关于合并：汞/ Git与SVN的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！