我试图将一个主干合并到一个分支，但最终导致很多树冲突，没有合并任何文件。为了解决这些冲突，我只是打开文件并手动复制内容，这违背了合并操作的目的。 将树干合并到分支的正确方法是什么？（在subclipse中）？
答案 0 :(得分：0)
该分支是如何创建的？是使用svn cp创建的，还是手动将这些文件复制到该分支中？
让我们看看以下内容：
$ svn mkdir trunk
$ vi trunk/foo trunk/bar
$ svn add trunk/foo trunk/bar
$ svn commit -m"Added foo and bar to trunk"
现在你在主干上有两个文件。
$ svn mkdir --parents branches/1.0
$ cp trunk/* branches/1.0/
$ svn add branches/1.0/*
$ svn commit -m"Duplicated files onto branch"
我所做的是在1.0分支上创建两个完全不同的foo和bar。根据Subversion这两个文件完全没有任何关系。如果您在1.0分支上进行更改，并尝试将这些更改合并回主干，则会出现与“本地添加，传入添加”等消息的大量冲突。
上述用户应该做的是：
$ svn cp --parents trunk branches/1.0
$ svn commit -m"Branched trunk and not merely duplicate files"
现在，Subversion了解了trunk和1.0分支上的文件之间的关系。合并将顺利进行。
这是打破合并的另一种方法：
$ svn delete trunk/foo
$ svn commit -"deleted foo"
$ svn cat -rPREV trunk/foo@PREV > foo
$ svn add foo
$ svn commit -m"Added foo back in. Shouldn't have deleted it.
根据Subversion，现在在trunk中有两个完全不同的名为foo的文件。有你删除的文件，还有你添加的文件。这两个文件彼此无关。想象一下，如果我（使用svn cp的正确方式）分支到1.0分支，然后删除并复制foo。将1.0分支合并回主干将发生冲突，因为分支上的foo与主干上的foo没有关系。
要恢复文件，您需要复制已删除的修订版（或使用svn merge -c）。
$ svn cp -rPREV http://svn.repo/svn/trunk/foo@PREV .
$ svn commit -m"Actually old foo now has been restored! Merges will work"
如果分支不正确，或删除并重新将文件重新添加回主干，则会出现冲突。您可以尝试使用--ignore-ancestory参数，并且可以在运行实际合并之前使用--dry-run来测试合并。
如果您手动合并，则可以使用svn merge --record-only来记录您执行合并而不实际执行合并的事实。这可能有助于您下次进行合并，因为您至少重新编码了您手动完成的操作。