tags:

views:

560

answers:

2

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?

+2  A: 

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.

Avi
Thanks! I realized after committing it to my branch that it's something that should have been done on the trunk instead. Otherwise I would have just done it the way you suggested.
Mike
A: 

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

Jesse
How is that tool any different than the tortoise merge tool?
SeanJA