tags:

views:

1349

answers:

3

Hi,

I have the following problem using subversion:

I'm currently working on the trunk of my project and plan to do some refactoring (which includes renaming files or moving files to different directories).

At the same time someone else is working on the same project on a branch.

At some time I want to merge the changes made on the branch back to the trunk. That includes changes made to files (on the branch) that have been renamed on the trunk.

I did some tests and it seems that either subversion is not capable of following these changes or I'm missing someting (which is what I hope for). I tested this using the following script (should work in bash, assumes an svn repository at "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'

Any help is greatly appreciated.

Edit: Perhaps the process suggested by mikegrb could by somewhat automated by first generating a map of renamed files (old->new) from the svn log command on the trunk:

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}

Now use this map to change filenames in the patch file generated on the branch.

Original:

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

modified:

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

Just an Idea, haven't done it yet.

A: 

It's likely that you'll have to rename them in the branch. Can you merge the revision that renamed them from the trunk to branch? That might save some time. Otherwise, you'll have to rename them in the branch. Then try the merge back to the trunk.

mspmsp
+5  A: 

Unfortunately, this is one of the limitations of subversion. When we recently had a similar situation to deal with our solution was to create one giant diff for the branch and then go through it file by file manually patching trunk. Files that have been renamed and are not found will cause patch to prompt for the file name to patch. Very sub optimal. Watch out for binary files which won't show in the diff. This was one of the big factors that prompted us to evaluate other version control systems and ultimately decide to transition to git.

mikegrb
technically Git doesn't have true rename support either. They however do perform guessing, which is better then SVN. Bazaar is the only open source VCS that supports true renames.
caspin
+7  A: 

I think this is an existing subversion bug - but don't hold your breath, its been open since 2002.

Chris Kimpton
It looks like they pushed this bug out to version 1.8. Which is just another way of saying 'not yet'. Since it's been open since 2002 it's beginning to look more and more like 'not ever'.
caspin