svn - SVN对mergeinfo的实际用途是什么？

Question

我很早就听说过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 @ branch A保持不变？

如果无法弄清楚，svn对 mergeinfo有什么实际用途？

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

谢谢

Answer 1

Subversion中有两种合并类型：


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


假设您正在处理中继，并且您需要完成一项特殊功能。您创建功能A分支。在使用功能部件时，您希望将您在主干上所做的工作包括在功能部件A中，以便您可以跟上其他所有人的工作。 Subversion将使用三点合并。

Subversion从分支发生的角度看主干和分支Feature A之间的差异。最近的共同祖先。然后，它考虑对功能A所做的所有更改（您不想触摸）以及在主干上完成的代码更改。

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

svn:mergeinfo进入哪里？您不想合并两次相同的更改，因此Subversion使用svn:mergeinfo属性跟踪更改。如果Subversion看到修订版5中的干线更改已被合并，则不会重新合并该更改。这很好。

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

这里有点问题。我们跟踪了通过svn:mergeinfo从主干合并到Feature分支的内容。但是，由于我们还没有从Feature分支合并到主干，因此这里没有svn:mergeinfo。如果尝试从Feature分支到中继的正常三点合并，则中继将假定Feature分支中的所有更改都应合并回中继。但是，其中许多功能实际上是已合并的主干更改。

确实，在这一点上，我们要进行两点合并。合并后，我们希望主干和Feature分支完全匹配。毕竟，我们现在已经定期将中继合并到Feature分支中。我们要做的是将这些功能重新整合到主干中。因此，主干将与功能分支相同。

在Subversion 1.8之前，您必须通过运行svn merge --reintegration强制进行重新集成合并。现在，Subversion将查看合并历史记录，并确定何时应该进行重新整合合并。



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


修订版10：我对Trunk做了最后的更改，需要将这些合并到Feature分支中。
修订版11：我将中继合并到Feature分支中。 svn:mergeinfo将显示从修订版1到修订版10的所有中继线都在Feature分支中。由于主干上的最后一个更改是修订版10，因此这很合理。
修订版12：我将功能分支的修订版11合并到了主干中。这是重新整合合并。之后，Feature分支上的内容和主干中的内容应该完全一致。


现在，这是踢脚！


修订版13：我对中继进行了另一处更改。


现在，我想将此合并到我的Feature分支中（创建修订版14）。现在，功能分支上的svn:mergeinfo表示什么？它表示从修订版1到修订版10的中继已合并到Feature分支中。但是，主干的修订版12和修订版13尚未发布。因此，Subversion将想要将版本12和版本13合并回Feature分支。

但是请稍等！

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



有两种处理方法：


推荐的方法：一旦将功能分支重新集成到主干中，请删除该分支。锁定它。永远不要再使用它。别碰！这并不像听起来那样糟糕。重新整合合并后，您的主干和该功能分支仍然会匹配。从主干中删除并重新创建分支不会很糟糕。
起作用的棘手方法：我们需要做的就是欺骗Subversion，使他们认为版本12（或重新集成合并更改）已经合并到我们的Feature分支中。我们可以使用svn:mergeinfo属性来解决问题。而且，我经常这样做。在显示trunk:1-11的地方，我将其手动更改为trunk:1-12。

这很棘手，但又太棘手，而且很有风险，因为Subversion已经为您提供了一种无需手动更改即可操作svn:mergeinfo的方法。


这称为仅记录合并。

$ 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."

这将更改功能分支上的 svn:mergeinfo，而不会影响文件的实际内容。没有真正的合并完成，但是Subversion现在知道主干的修订版12已经在Feature分支中。完成此操作后，就可以重用功能分支。



现在看一下您的图：将分支B合并到分支A中时，您将所有从B进行的更改合并到A中，并且 svn:mergeinfo进行了跟踪。当您将分支B合并回分支A时，您已经拥有分支A中分支B的所有更改，并且您不希望将这些更改带回到分支B。您应该使用重新集成合并：

$ 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

现在，如果我们想继续使用分支A进行进一步的更改：

$ 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"

我希望这能解释一下 svn:mergeinfo的工作原理，为什么必须知道您使用的是普通的三点合并还是两点重新整合合并，以及如何在激活后重新激活分支。完成了重新整合合并。

只要牢记这一点，Subversion合并就可以很好地工作。