Reorganizing a subversion repository with branches

Question

I am trying to reorganize a subversion 1.6 repository that has branches. It appears that if you move a file in the trunk and that file has changes in a branch, when those changes are merged into the branch, they are no longer there.

I will try to illustrate below:

1. Repo before move
    trunk/a.txt
    trunk/b.txt
    branches/feature/a.txt
    branches/feature/b.txt

2. File branches/feature/b.txt is changed.

3. Repo reorganized
    trunk/a.txt
    trunk/new-location/b.txt
    branches/feature/a.txt
    branches/feature/b.txt

4. Changes from trunk merged to feature
    trunk/a.txt
    trunk/new-location/b.txt
    branches/feature/a.txt
    branches/feature/new-location/b.txt

The folder branches/feature is a copy of trunk.

Upon completion of step 4, all changes to file b.txt from feature branch are no longer there.

I thought this was fixed in svn 1.5?

If this is not an option, i still need to somehow reorganize my entire repostory. Doing the move when the branches have all been merged into the trunk is not an option. I always have at least 1 branch plus trunk at any one time.

Answer 1

Provide details on steps 3 and 4. Subversion merges are not the same as copies.

Answer 2

You'll need to make sure you use the SVN rename method for step 3 to make sure the file location remains associated with future changes.

(I'm pulling this one out of ...well I'm not sure about the following) There is an issue with ancestry when moving/renaming files. Make sure that when you merge the ignore ancestry option is not selected.

Answer 3

Merging moved files is a known problem. However, subversion does warn you with this message if it doesn't find the merge target:

Skipped missing target: 'baz.c'

If you see this message, you may need to take manual action. If the file was moved and the new location should receive the changes, then you can consider doing a subtree merge between the renamed entities.

I'm not aware of any version control system which does such merges automatically. edit: looks like in mercurial, such merges do follow copies.