合并重命名文件夹时的SVN树冲突

Question

我正在使用 TortoiseSVN 将 trunk 的最新更改合并到 branch-B，包括文件夹重命名。

在此之前，我将 branch-A 重新集成到 trunk 中。在该分支中，一个文件夹已被重命名，并且其中的文件已被更改。 Branch-B 包含对这些文件的不同修订，但该文件夹仍具有原始名称。

当将 trunk 合并到 branch-B 时，SVN 只是简单地将重命名的文件夹添加为新文件夹，并在最初命名的文件夹上报告树冲突。文件修订本身永远不会合并，我只剩下两个文件夹。我尝试了多种选项来获得最干净的合并，同时保留所有适当的 svn:mergeinfo，但似乎没有任何效果。

有人知道干净地完成此合并的正确方法吗？

TortoiseSVN 1.8.10，Subversion 1.8.11

这是一个视觉效果：

/trunk (before reintegrating branch-A)
  /Folder1
    file1
    file2
    file3

/trunk (after reintegrating branch-A)
  /Folder1-Renamed
    file1-change1
    file2-change1
    file3

/branch-B
  /Folder1
    file1-change2
    file2-change2
    file3

TL;DR：当包含文件夹已在其中一个分支中重命名时，我如何干净地合并两个分支之间的文件修订？

Answer 1

在 Subversion 中没有真正干净的方法来解决这样的结构树冲突。基本上，你需要做的是：

• 将trunk 合并到branch-B 工作副本中
• 手动在branch-B 中创建对file1 和file2 的更改的差异，并将它们应用到新合并的Folder1-Renamed 目录中的相应文件中
• 删除现在已过时的Folder1 目录
• 确保一切正常
• 接受当前状态为正确状态（另见http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html）
• 提交

抱歉，没有比使用 svn 更容易的了。我非常喜欢在某些类型的团队设置中使用 Subversion，但是树冲突的噩梦（以及它们神秘且容易出错的解决机制）经常让我们想哭（并且永远切换到 git）。

Answer 2

您可以通过这种方式在命令行上执行此操作。等效步骤应该适用于 TortoiseSVN 或其他客户端。

假设重命名是在主干的修订版 1000 中完成的，并且您正在将主干合并到分支 B：

# merge everything before the rename
svn merge ^/trunk@999
svn commit -m 'merge from trunk up to 999'
svn update

# merge everything starting with the rename
svn merge ^/trunk
# for tree conflicts on directories, accept the incoming deletion, and make note of the path

# for each tree conflict, take your changes to the old folder,
# and re-apply them to the new folder using a two-URL merge,
# then delete the unnecessary mergeinfo.
# e.g. for Folder1 vs Folder1-renamed:
svn merge ^/trunk/Folder1@999 ^/branches/Branch-B/Folder1 ./Folder1-renamed
svn propdel svn:mergeinfo ./Folder1-renamed

svn commit -m 'merge from trunk'