Merge with no conflicts, the code doesn't compile: should I fix it before commit?

Question

I'm working with Subversion 1.7.x, and am doing my development on a branch .

From time to time I merge from trunk to keep the branch up to date.
During the latest merge, though, the incoming code, while totally correct in the trunk , doesn't compile in the branch .
And that's expected, because the code changed in the trunk has partially been rewritten in the branch several revisions ago.

Notice that the merge operation completed cleanly, there were no conflicts.
For the sake of clarity, when I say merge I mean the operation that modifies the working copy with code from another branch, no commit involved, ie just the svn merge [source] [dest] .

Since that branch will ultimately be reintegrated to the trunk , I guess I have two alternatives:

1. fix the compilation errors before committing the merged code;
2. merge from trunk ; commit (the merged code without edits); edit the code to fix the compilation issues; commit again (ie fix the compilation issues subsequently, performing a new, separate commit).

If I edit the merged code before committing it (ie I go with #1), will those changes be lost when reintegrating the branch?

Answer 1

Short answer is: no, changes will not be lost.

A little bit more details.
Reintegration merge differ from 'regular' sync merge, because it copy branch to trunk, so both become identical[1]. It can be expressed as 'apply difference between branch and trunk into trunk(wc)'. Of course reintegrate merge should actually be reintegrate merge. Subversion 1.8 somehow guess, earlier versions require --reintegrate argument during merge.

Update:

[1] Actually, I made couple tests and found that result will be identical only if you merge into working copy updated to last synced revision. For example, if you sync trunk 1-100 to branch, then create in trunk 10 more additional revisions, then reintegrate branch into trunk - here can be differences.

I personally prefer sync branch to latest revision in trunk, reintegrate and then compare folders for binary identity. Just in case :)