TortoiseSVN approaches to resolve Tree Conflicts

Question

TortoiseSVN can help with several kinds of tree conflicts using Edit Conflict window.

The problem is that in case of "... upon merge" conflict types TortoiseSVN can't guess which files need to be merged.

For example, (case: local missing, incoming delete upon update)

• Developer A working on trunk modifies file Foo.c and commits it to the repository.
• I working on branch move file Foo.c to Bar.c and commit it to the repository.

A merge of developer A's changes to my branch working copy results in a tree conflict:

• Bar.c is already in my working copy with status 'normal'
• Foo.c is marked as missing with a tree conflict

In most cases I need to merge Developer A’s changes to Foo.c into the renamed Bar.c.

But how can I do it?

File Foo.c with Developer A’s changes does not present in my branch WC.

The TortoiseSVN Help says “Note that if you copy the missing file from the repository and then mark as resolved, your copy will be removed again. You have to resolve the conflict first.”

So, should I need to chechout trunk to have access to Foo.c file for merge? Is there more simple approach to solve this problem?

This problem (how TortoiseSVN can solve tree conflicts) is very critical for me and our developers.

Could you help me?

Answer 1

You may use a "Two URL Merge" in order to merge changes from Foo.c on 'trunk' into your branched and renamed Bar.c.

cd branch/B
svn merge http://www/svn/svnroot/branches/B/Bar.c http://www/svn/trunk/Foo.c Bar.c

Whereas branch/B is a working copy.

To finally remove the conflict developer A and B should agree on the same filename. Using different files for the same code might not be desirable.

EDIT: From looking at how 'other' vcs approach this issue, I would like to quote from the paragraph 'Renaming files and merging changes':

If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to “simply work,” but not all revision control systems actually do this.)

Maybe a reason to give Mercurial a try.

Answer 2

I like zellus's solution. You could also merge the move of the file into the branch, and then perform the merge back to trunk.

What I do when merging big branches, is merge trunk into the branch first, resolve all the conflicts (including tree conflicts), then merge the result back to trunk. This keeps trunk more stable for longer during the merge period, too.