There should be no tree conflict in this scenario unless certain merge-tracking information is missing.
In order to check this, run the following command:
$ svn switch ^/branches/COKE
$ svn mergeinfo --show-revs=merged ^/trunk
This prints a list of revisions merged from trunk into the COKE branch. Can you find there a revision when you've modified FILE1 at trunk? Most probably there's no that revision.
It's a common case when SVN user merges modification from one branch into another, but then commits not the whole working copy (i.e. including the root directory) rather just those files modified by merge.
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 svn:mergeinfo property. Subversion uses this property to track merges, so you have to commit the whole working copy.
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 trunk into the COKE branch the second time, Subversion detected that FILE1 was deleted at trunk and at the same time it was modified at COKE branch (by step 2). As result it marked the file with a tree conflict (local edit, incoming delete upon merge).
How to fix that?
Now you have to fix the merge-tracking information for the branch COKE. In order to do that repeat the step 2 with --record-only option and a proper revision specified:
$ 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 trunk you were trying to merge.