Question

I’ve created a feature branch to work in parallel with the trunk.

In the brach I’ve done a big amount of structure (folder) changes. For example, I’ve moved folders that before were on:

application/views/scripts/users/*

to:

application/modules/user/views/scripts/users/*

Now, I’m trying to do a merge from the trunk to this feature branch and I’m founding a million of tree conflicts! And the issue is that since this tree conflicts appear, no file inside that tree is merged against anything.

I mean, I find a tree conflict on:

application/views/scripts/users (SVN message: "The last merge operation tried to modify the directory 'users', but it was deleted, moved or renamed locally")

and none of the files and other folders that were inside that path have been merged.

Is there a way to recover the “link” between the original location of a folder and the current one?

Can I do something to deal with this issue?

Answer 1

More than a solution, I can give a workaround, that is the one that I’ve used, becuase it seems that there’s not really a solution for this.

After a little research I’m close to sure that SVN doesn’t support this kind of feature for merging. In the documentation of TortoiseSVN it is said that:

Local missing, incoming edit upon merge

Developer A working on trunk modifies Foo.c and commits it to the
repository

Developer B working on a branch moves Foo.c to Bar.c and commits it to
the repository

A merge of developer A’s trunk changes to developer B’s branch working
copy results in a tree conflict:

Bar.c is already in the working copy with status ‘normal’.

Foo.c is marked as missing with a tree conflict.

To resolve this conflict, Developer B has to mark the file as resolved
in the conflict editor dialog, which will remove it from the conflict
list. She then has to decide whether to copy the missing file Foo.c
from the repository to the working copy, whether to merge Developer
A’s changes to Foo.c into the renamed Bar.c or whether to ignore the
changes by marking the conflict as resolved and doing nothing else.

This means that you have to decide, one tree conflict at a time, what to do. And this is not the worst part. What is really unacceptable in my case is that every time I do a new merge from the trunk to this branch I’ll be forced to deal with this conflicts again.

The workaround

Replicate the structural changes made on the branch into the trunk (with its required changes on code) and make it work with them.

After commiting this changes both structures of files, the trunk and the branch will match, so later merge operation won’t complain anymore.