Menu
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?
851
You can use svn merge to “undo” the change in your working copy, and then commit the local modification to the repository. All you need to do is to specify a reverse difference. (You can do this by specifying --revision 392:391 , or by an equivalent --change -392 .)
Merging ranges of revisionsEdit To merge a range of revisions, use svn merge -r start:end from to where start and end are revision IDs. This will merge all revisions starting at start+1 up to and INCLUDING end . Note: it will NOT include the first revision (ex: -r3:45 will merge 4 through 45).
Reverse Merge - Use Subversion reverse merge to roll back a change or multiple changes that have been committed to the repository, and then apply this to your working copy.
In order to be certain that you retain all the modifications made by you or other developers that you want to keep and none of the modifications you don't want, I think you probably need to manually merge all the conflicted files using labview's LVMerge graphical merging tool. I've had good success using it in conjunction with Tortoise SVN - here are instructions for how to integrate LVMerge into SVN and using it to resolve version conflicts:
http://www.dmcinfo.com/Blog/articleType/ArticleView/articleId/136/Using-LVmerge-LabVIEW-Merge-Tool-with-TortoiseSVN.aspx
42
If the order of the changes on the branch doesn't matter too much, you might be able to merge just those changes back to the trunk, and then merge the rest of them when the feature is ready to reintegrate.
If possible, I would just avoid the whole situation, by waiting with the change until the branch is ready to merge.
In most cases, if it is a change that should be done on the trunk right away, I would advise doing the change on the trunk, not the branch, and then merge from the trunk to the branch as you normally do.
145
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
