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

Question

我使用subversion有以下问题:

我目前正在研究项目的主干,并计划进行一些重构(包括重命名文件或将文件移动到不同的目录).

与此同时,其他人正在分支机构上工作同一个项目.

在某些时候,我想将分支上所做的更改合并回主干.这包括对已在主干上重命名的文件(在分支上)所做的更改.

我做了一些测试,似乎颠覆不能跟随这些变化,或者我错过了某些(这是我希望的).我使用以下脚本测试了这个(应该在bash中工作,在" http:// myserver/svn/sandbox "中假设一个svn存储库):

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建议的过程可以通过首先从trunk上的svn log命令生成重命名文件(old-> new)的映射来进行自动化:

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

我认为这是一个现有的颠覆错误 - 但是不要屏住呼吸,它自2002年开始营业.

Answer 2

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