什么'；s SVN'；mergeinfo的实际用途是什么？

我早就听说svn的合并冲突问题

我想，当我在几年前得知svn实现了一个名为

mergeinfo

的特性时，我松了一口气。它的引入似乎可以让svn在出现合并问题时拥有足够的信息来解决合并问题。直到我陷入以下情况：

上述图表的脚本示例：

SVN=${SVN:-svn}
SVNADMIN=${SVNAMDIN:-svnadmin}

rm -rf repo wc

$SVNADMIN create repo

$SVN co file://$PWD/repo wc
cd wc

# r1
$SVN mkdir trunk branches
$SVN ci -m 'structure'
$SVN up

# r2
echo 2 > trunk/t.txt
$SVN add trunk/t.txt
$SVN ci -m 'add t.txt'
$SVN up

# r3
$SVN cp trunk branches/A
$SVN ci -m 'create branch A'
$SVN up

# r4
echo 4 > branches/A/a.txt
$SVN add branches/A/a.txt
$SVN ci -m 'add a.txt'
$SVN up

# r5
$SVN cp trunk branches/B
$SVN ci -m 'create branch B'
$SVN up

# r6
echo 6 > branches/B/b.txt
$SVN add branches/B/b.txt
$SVN ci -m 'add b.txt'
$SVN up

# r7
$SVN merge ^/branches/B branches/A
$SVN ci -m 'merge branch B into A'
$SVN up

# r8
echo 8 > branches/A/d.txt
$SVN add branches/A/d.txt
$SVN ci -m 'add d.txt'
$SVN up

# r9
$SVN merge ^/branches/A branches/B

如果svn保存每个分支的来源历史，为什么它不能理解

b.txt

未被触及@

分支A

如果不能弄清楚这一点，svn对

mergeinfo

的实际用途是什么

如果svn无法处理这个问题，那么在这方面是否有可能创建一个工具来帮助我（即自动解决此类无脑问题…）？我猜也许有一个已经存在了

---

感谢您误解了mergeinfo的含义和用法-它仅适用于（对于此节点）已合并的修订和合并来源，以便不要两次合并修订，内容无关

Subversion中有两种类型的合并：

三点合并

两点合并（也称为重新合并）

假设您正在处理trunk，您需要完成一个特定的功能。可以将要素创建为分支。当您在特性上工作时，您希望您在主干上所做的工作包含在特性A中，这样您就可以跟上其他人所做的工作。Subversion将使用三点合并

Subversion将从分支发生的那一点来看主干和分支功能A之间的区别。最近的共同祖先。然后，它会考虑对功能A所做的所有更改（您不想触摸这些更改），以及对trunk所做的代码更改

Subversion随后将合并主干上的更改，而不会覆盖分支上所做的更改。标准的合并过程，Subversion做得很好

svn:mergeinfo

从何而来？您不希望合并两次相同的更改，因此Subversion使用

svn:mergeinfo

属性跟踪更改。如果Subversion看到来自修订版5的主干中的更改已经被合并，它将不会重新合并该更改。这个很好

现在，您已经完成了您的功能，并且希望将这些更改合并回主干中。您执行最后一次主干到分支的合并，提交这些更改，然后现在从要素分支合并回主干

这里有点问题。我们通过

svn:mergeinfo

跟踪从主干合并到功能分支的内容。但是，由于我们还没有从功能分支合并到主干，因此那里没有

svn:mergeinfo

。如果我们尝试从要素分支到主干的常规三点合并，主干将假定要素分支中的所有更改都应合并回主干。然而，这些特性中的许多实际上是已经合并的主干更改

老实说，在这一点上，我们想要做一个两点合并。我们希望主干和特征分支在合并后完全匹配。毕竟，我们现在一直在定期地将主干合并到功能分支中。我们要做的是将这些特性合并回主干中。因此，主干将与特征分支相同

在Subversion 1.8之前，您必须通过运行

svn merge--replication

强制重新整合合并。现在，Subversion将查看合并历史并确定何时应该进行重新整合合并

---

现在是棘手的部分。仔细看一下修订号。这些将是非常非常重要的

• 修订版10：我对主干做了最后的更改，需要将这些更改合并到功能分支中
• 修订版11：我将主干合并到要素分支中<代码>svn:mergeinfo将显示从版本1到版本10的所有主干都在功能分支中。由于trunk上的最后一次更改是修订版10，因此这非常有意义
• 修订版12：我将要素分支的修订版11合并到主干中。这是一次重新融合。在此之后，功能分支上的内容和主干中的内容应该完全一致

现在，踢球的人来了

• 第13版：我在行李箱中做了另一个更改

现在，我想将其合并到我的要素分支中（创建修订版14）。现在，feature分支上的

svn:mergeinfo

说了什么？它表示从修订版1到修订版10的主干已合并到要素分支中。但是，主干的第12版和第13版尚未发布。因此，Subversion希望将修订版12和修订版13合并回功能分支

等一下

trunk上的修订版12是我将功能分支中的所有更改合并回trunk！也就是说，修订版12已经包含了我在功能分支中所做的所有修订更改。如果我将修订版12合并回我的功能分支中，我会说主干上修订版12中的所有更改（实际上是在功能分支上进行的更改，并合并到主干中）都需要合并到功能分支中。但是，这些更改也发生在Feature分支上。你能说合并冲突吗？我就知道你可以

---

有两种方法可以处理此问题：

• 推荐的方法：将功能分支重新整合回主干后，删除该分支。锁上它。永远不要再使用它。不要碰！这并不像听起来那么糟糕。合并后，您的主干和该功能分支仍将匹配。从主干中删除和重新创建分支不会那么糟糕
• 运作的微妙方式：我们需要什么

  $ svn co svn://branches/feature_a
  $ cd feature_a
  $ svn merge --record-only -c 12 svn://trunk
  $ svn commit -m "Adding in the reintegration merge back into the feature branch."
  

  $ cd $branch_a_working_dir
  $ svn merge $REPO/branches/B
  $ svn commit -m "Rev 7: All of my changes on Branch B are now in A"
  $ vi d.txt
  $ svn add d.txt
  $ svn commit -m"Rev 8: I added d.txt"
  $ cd $branch_b_working_dir
  $ svn merge --reintegrate svn://branch/A  # Note this is a REINTEGRATION merge!
  $ svn commit -m"Rev 9: I've reintegrated Branch A into Branch B
  

  $ cd $branch_a_working_dir
  $ svn merge -c 9 --record-only $REPO/branches/b
  $ svn commit -m"I've reactivated Branch A and can make further changes"