Subversion没有将更改合并到重命名的文件中？

Question

我在使用 subversion 时遇到以下问题：

我目前正在处理我的项目的主干并计划进行一些重构（包括重命名文件或将文件移动到不同的目录）。

同时其他人正在分支上从事同一个项目。

有时我想将在分支上所做的更改合并回主干。这包括对已在主干上重命名的文件（在分支上）所做的更改。

我做了一些测试，似乎任何一个颠覆都无法遵循这些变化，或者我错过了一些东西（这是我所希望的）。我使用以下脚本对此进行了测试（应该在 bash 中工作，假设 svn 存储库位于“http://myserver/svn/sandbox”）：

svn co http://myserver/svn/sandbox

cd sandbox/

mkdir -p MyProject/trunk MyProject/branches MyProject/tags

cat - <<EOF >MyProject/trunk/FileOne.txt
Test
1
2
EOF

svn add MyProject

svn commit -m "init"

# create a branch
svn copy http://myserver/svn/sandbox/MyProject/trunk http://myserver/svn/sandbox/MyProject/branches/Branch_1 svn copy http://myserver/svn/sandbox/MyProject/trunk http://myserver/svn/sandbox/MyProject/branches/Branch_1

# rename the file
svn move MyProject/trunk/FileOne.txt MyProject/trunk/FileTwo.txt

svn commit -m "renamed file"

svn update 

# change the content of FileOne in branch

cat - <<EOF >MyProject/branches/Branch_1/FileOne.txt
Test
2
3
EOF

svn commit -m "changed branch"

# I now try to merge the changes in FileOne back to FileTwo
cd MyProject/trunk/
svn merge -r1:HEAD http://myserver/svn/sandbox/MyProject/branches/Branch_1
# but this yields the following message:
# Skipped missing target: 'FileOne.txt'

非常感谢任何帮助。

编辑： 也许 mikegrb 建议的过程可以通过首先从主干上的 svn log 命令生成重命名文件（旧->新）的映射来稍微自动化：

svn log -v
------------------------------------------------------------------------
r33 | sme | 2008-10-09 15:17:54 +0200 (Do, 09 Okt 2008) | 1 line
Changed paths:
   D /MyProject/trunk/FileOne.txt
   A /MyProject/trunk/FileTwo.txt (from /MyProject/trunk/FileOne.txt:31)


resulting map: {FileOne.txt => FileTwo.txt}

现在使用此映射来更改分支上生成的补丁文件中的文件名。

原文：

Index: FileOne.txt
===================================================================
--- FileOne.txt (.../trunk)     (revision 31)
+++ FileOne.txt (.../branches/Branch_1) (revision 34)
@@ -1,3 +1,3 @@
 Test
-1
 2
+3

修改：

Index: FileTwo.txt
===================================================================
--- FileTwo.txt (.../trunk)     (revision 31)
+++ FileTwo.txt (.../branches/Branch_1) (revision 34)
@@ -1,3 +1,3 @@
 Test
-1
 2
+3

只是一个想法，还没做。

Answer 1

我认为这是一个现有的颠覆 bug - 但不要屏住呼吸，它自 2002 年以来就已开放。

Answer 2

不幸的是，这是颠覆的局限之一。当我们最近遇到类似情况时，我们的解决方案是为分支创建一个巨大的差异，然后逐个文件手动修补主干。已重命名且未找到的文件将导致patch 提示输入要修补的文件名。非常次优。注意不会在 diff 中显示的二进制文件。这是促使我们评估其他版本控制系统并最终决定过渡到 git 的重要因素之一。

Answer 3

您可能必须在分支中重命名它们。您可以合并将它们从主干重命名为分支的修订吗？这可能会节省一些时间。否则，您必须在分支中重命名它们。然后尝试合并回主干。

Answer 4

一种解决方法是在将主干与分支同步之前将分支与主干同步。

不同之处在于，trunk to branch 有一个文件可以应用更改（移动）到，而 branch to trunk 没有一个文件可以应用更改（修改）到。这仅仅是因为 SVN 似乎没有跟踪文件被移动/重命名的位置。我不知道为什么没有，希望有一个很好的理由。

例子：

• rev 1：/trunk/foo.txt 移至 /trunk/folder/foo.txt
• rev 2：/branches/mybranch/foo.txt 已修改

如何将 foo.txt 更改合并到主干？

解决方案：

1. 将所有修订版从主干合并到 mybranch 并提交。这将导致 foo.txt 移动。
2. 将所有修订从 mybranch 合并到 trunk。这将更新 foo.txt 的内容，因为它们现在具有相同的路径。

注意：如果您在 trunk 和 mybranch 上移动/重命名了不同的文件，那么您就是在兜风。我想您将不得不有选择地合并更改，以便您首先在两个方向上移动/重命名，然后合并更改。