I have what I thought was a simple scenario - using TortoiseSVN:
1) I made a branch (B2) of an application (to work on implementing image sprites & JAWR).
2) Testing & development went on as normal on the trunk.
3) I re-based the branch a couple of times over the last few days by:
3.1) Merged trunk (by range of revisions) to my branch-b2 working copy, resolving conflicts during the merge.
3.2) (after testing branch-b2), I commit the re-based branch-b2.
This all worked as I expected. But merging the branch back into the trunk is having its way with me:
4) After all updates committed in branch-b2; I make sure I do an SVN Update on trunk and branch-b2.
5) Then, I try to merge (range of revisions) from branch-b2 into the trunk. However, for any new file that had been added to the trunk, and subsequently added to branch-b2 when I rebased it, I get a tree-conflict. I'm not sure what the proper way is to resolve these conflicts.
The most typical advice I've seen is to either delete the tree-conflict files from the trunk, then merge the branch over; or delete the entire trunk, copy the branch files over, and then commit them as a new version in the trunk. Neither of those options seems like a good idea- first one is a pain, and both seem like they would lose file revision histories.
What'd I do wrong, and how do I fix it?
Sounds like you're using the pre-1.5 merge style and trying to reintegrate the branch into trunk. In that case, what you want to do is first ensure all the trunk changes have been merged in to the branch, and then instead of range-merging the branch to a working copy that points to the trunk, you want to merge "FROM trunk@HEAD TO branch@HEAD" with the working copy pointing to trunk. In essence:
"Give me all the changes I'd need to make trunk identical to branch".
This works if you've already merged all the trunk changes to the branch, because then the only difference between trunk and branch are the changes made in the branch.
Make sense? :)
I investigated the same problem.
It is "feature" in Tortoise SVN 1.6.5.
TortoiseSVN 1.5 works fine with our repositoty (SVN 1.5).
TortoiseSVN 1.6.5 when rebasing adds files from mainline as NEW (without saving merge-history).
And reintegrating branch resuls in treating those files as conflicting with mainline.
I solved the problem by using feature of TortoiseSVN 1.6 "reintegrate branch". It's specifically purposed for feature-branches.
-- Alexey Korsun
Here's a little more info to contribute to @Rytmis answer that helps me keep this straight.
High-level steps of making the trunk exactly like a branch or tag:
- Checkout from the trunk.
- Using working copy of trunk, merge from trunk to branch/tag.
- Commit.
Example 'svn' command line commands:
svn checkout <trunk url>
cd trunk
svn merge <trunk url> <branch/tag url>
svn commit -m "<message>"
I could not really figure out how the above solution was to work so my work around is different. First I made sure the branch contained all the changes from the trunk.
1)I got a fresh copy of the trunk. 2)I exported the branch to a temporary location using the tortoise svn export. 3)I used windows explorer to copy the entire branch tree over to the trunk and overwrote all files 4)I used the check for changes command on tortoise and included all unrevisioned files checkbox. 5)I selected all the files and clicked add.
You should use solutions that have not been built so the unrevisioned files do not include output.
I cant wait until we upgrade to 1.5+
Select revisions to Merge while selecting "Merge a range of rivisions" option using TortoiseSVN. This will prevent tree conflicts for same files coming again for each merge operation.
I think I solved that problem. 1. Right click "branch" which you merged. 2. Click Tortoise SVN >> Merge 3. "Merge a range of revisions" and Next 4. !!!CHECK "Reverse Merge"!!! , URL to Merge from "branch", specific range "recently merged revision", and Next 5. Next 6. SVN Commite
After that I can merge from branch into trunk.
来源：https://stackoverflow.com/questions/1008681/svn-unable-to-merge-branch-back-into-trunk-numerous-tree-conflicts