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? 🙂