In this scenario, there should be no tree conflicts if certain merge tracking information is missing.
To verify this, run the following command:
$ svn switch ^/branches/COKE $ svn mergeinfo --show-revs=merged ^/trunk
Sends a list of changes merged with the trunk to the COKE branch. Can you find the revision there when you changed FILE1 on the trunk? Most likely, there is no such version.
This is a common case when an SVN user merges a modification from one branch to another, but then does not commit the entire working copy (i.e. including the root directory), but simply files that have been merged.
Wrong:
$ svn merge ^/trunk --- Merging r5 through r6 into '.': M file.txt --- Recording mergeinfo for merge of r5 through r6 into '.': U . $ svn commit FILE1
The problem is that the root directory stores the svn: mergeinfo property. Subversion uses this property to track merges, so you need to commit the entire working copy.
On right:
$ svn merge ^/trunk --- Merging r5 through r6 into '.': M file.txt --- Recording mergeinfo for merge of r5 through r6 into '.': U . $ svn commit .
When you tried to merge the trunk into COKE branches a second time, Subversion discovered that FILE1 was deleted on the trunk and at the same time it was changed in the COKE branch (to step 2). As a result, he marked the file with a tree conflict (local editing, inbound deletion when merging).
How to fix it?
Now you need to fix the merge information for the COKE branch. To do this, repeat step 2 with the -record-only option and the corresponding version:
$ svn merge --record-only -cN ^/trunk --- Recording mergeinfo for merge of r5 through r6 into '.': U . $ svn commit .
Where N is the modification of FILE1 in the body that you tried to combine.