Question

So I have this project with concurrent work going on in 2 releases, the trunk and branch1. At some point I am told “don’t make any more builds for rel1, fix those bugs in rel2.” So I make bugfixes in branch1 that could also apply to the trunk. Later I am told “It will be a big PITA if we relase rel1 with those known bugs. Please fix them in rel1 also.”

So, my question is (~/rel1 is a current, unmodified working copy of the trunk. RevM, RevN are revision numbers in branch1 for a range of revisions that I want to merge back into the trunk):

If I do a

cd ~/rel1
svn merge -r RevM:RevN ^/branch1 

how will it affect a later svn merge --reintegrate from the branch to the trunk? Bearing in mind that there are revisions in branch1 prior to RevM and there are going to be more after RevN. In particular, when I do eventually reintegrate, will it be as though I’d originally done the fixes in rel1 and merged them into rel2, as should have been done in the first place?

Answer 1

Cherry-picking changes from a branch into trunk is something that is always twisting my mind as well. Here is a solution that should work in your case, the trick being to block the cherry-picked changes from being merged into the branch again.

cd ~/rel1
svn merge -r RevM:RevN ^/branch1
svn commit -m "cherry pick RevM:RevN from branch1 into rel1"

Now suppose this commit has created RevX. Go into your branch and block this revision from future merge actions by using the --record-onlyoption.

cd ../branch1
svn merge -c RevX --record-only ^/rel1
svn commit -m "mark RevX as already merged to block it from future merge actions"

Now you should be able to merge further changes from rel1to branch1 again as usual and also to reintegrate your branch into rel1 once you’re done with it.