I am working on a feature branch and have some changes committed to my feature branch that will affect the other developers. I would like to commit those new changes to the trunk so that nobody is left scrambling to fix the break later; however, I do not want to commit the rest of the feature branch because it is not yet fully functional.
I branched off of the trunk at r109. My branch has had all changes to the trunk merged in up to r145. I committed my "will affect other developers" change to my branch in r152 and r153.
My thought process here was to svn switch my working copy to the trunk and then do:
svn merge svn://project/branch/myBranch -r 146:153 ./project
SVN complains about conflicts because the trunk contains the original version of one of the files I changed, whereas I am only merging in the latest changes (I made a few changes to that file in an earlier commit to my branch), and it also complains about conflicts with a file another developer changed in r149. Since my branch only contained merges from the trunk up to r145 before I committed, my branch doesn't reflect that change.
That's OK - the conflicts are easy to resolve, but my concern is that I will have trouble days from now when I want to reintegrate my complete branch into the trunk.
Alternatively, I could make the necessary changes to the trunk and then merge them into my branch, but I don't like that approach because the changes are already done in the branch. No point in doing them twice.
Does anybody have some experience with partial merges of feature branches into the trunk followed by full reintegration? What's the best strategy here?