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

我有以下问题使用subversion：Subversion没有将更改合并到重命名的文件中？

我目前正在研究我的项目的主干，并计划做一些重构（其中包括重命名文件或移动文件到不同的目录）。

与此同时，别人正在分支上的同一个项目上工作。

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

我做了一些测试，似乎颠覆不能跟踪这些变化，或者我错过了someting（这是我所希望的）。我测试了这个使用下面的脚本（应该在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命令在树干上重命名的文件（OLD->新）：

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

只是一个想法，还没有做呢。

来源

2008-10-09 sme

我觉得这是一个现有的颠覆bug - 但不要屏住呼吸，自2002年以来

来源

2008-10-09 14:20:58

看起来他们把这个bug推到了1.8版。这只是说'还没有'的另一种方式。自从2002年开放以来，它开始越来越像“没有”过。 – 2009-06-18 00:34:57

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

来源

2008-10-09 14:18:26 mspmsp

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

来源

2008-10-09 14:19:43 mikegrb

技术上Git没有真正的重命名支持。但是他们确实会进行猜测，这比SVN更好。 Bazaar是唯一支持真正重命名的开源VCS。 – 2009-06-18 00:32:49

一种解决方法是与分支同步主干前同步与主干分支它一直开着。

不同之处在于，主干分支有一个文件来应用更改（移动）到，而分支到主干没有文件来应用更改（修改）。这很简单，因为SVN似乎没有跟踪文件被移动/重命名的位置。我不知道为什么它不会，希望有一个很好的理由。

实施例：

转1：/trunk/foo.txt移动到/trunk/folder/foo.txt
REV 2：/branches/mybranch/foo.txt被修改

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

解决方案：

合并从主干的所有修订mybranch和承诺。这将导致foo.txt移动。
将mybranch的所有修订合并到中继。这将更新foo.txt的内容，因为它们现在具有相同的路径。

注意：如果您已经在trunk和mybranch上移动/重命名了不同的文件，那么您需要搭便车。我想你将不得不在变化中有选择地合并，以便在两个方向上先移动/重命名，然后合并更改。

来源

2012-08-22 14:54:43 angularsen

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

回答

相关问题