1

I noticed a(n) (anti-)pattern in my team:

We decide to implement a feature so we (svn) branch. While implementing the feature, we do refactorings that would benefit everyone if they could be merged back to the trunk right away. We wait until we are done with the branch, then reintegrate it with the trunk and everyone gets the feature + the refactorings.

Now the funny thing is very often the refactorings are of much higher (and immediate) value than the feature that set them in motion, so it would be very nice if somehow I could get them in the trunk immediately and don't wait till the branch is done with and gets reintegrated.

As far as I know you are not supposed to "merge" a branch with the trunk, but you do the other way around (merge the trunk with the branch frequently) until the branch is done and then you "reintegrate" the branch back with the trunk. If you do it the wrong way (merge a branch with trunk) then you mess things up (mergeinfo and stuff) and when the time comes, you get into all sorts of evil and you can't reintegrate smoothly.

Ideas ?

Ashkan Kh. Nazary
  • 21,844
  • 13
  • 44
  • 68

1 Answers1

1

It is possible. It even has a name - cherrypicking. Actually, cherrypicking is encouraged as long as it allows to avoid 'big bang' on branches merging. Moreover, if you do merging in the same direction (in your case from branch to trunk), it simplifies reintegration. Subversion remembers what have been merged previously using mergeinfo and excludes commits included into previous merges. It corresponds to the pattern Merge Early, Merge Often.

Principle is illustrated on the picture:

enter image description here

Difference with your case is that you need to merge in other direction, but it does not matter what will be the source branch and what will be the target branch.

So, don't be afraid of merging your refactorings into trunk. Actually, it will even simplify branch reintegration in the future.

altern
  • 5,829
  • 5
  • 44
  • 72
  • "So, don't be afraid of merging your refactorings into trunk. Actually, it will even simplify branch reintegration in the future." You really sure about that :-S I mean, judging from the svn-book, it's a no-no ... or perhaps I took'em over-seriously? – Ashkan Kh. Nazary Jan 11 '12 at 13:03
  • Could you please provide the example of link where I could read about 'no-no' merging from branch to the trunk? – altern Jan 11 '12 at 13:09
  • Excerpt from the SVN book: "Once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again. For this reason, if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk" The way I understand it, you are *not* supposed to merge a branch to the trunk in normal merge (non-reintegrate), just reintegrate and that only once when you are done. Or, I thought so ! – Ashkan Kh. Nazary Jan 16 '12 at 06:17
  • `--reintegrate` is just one type of a merge. it does 'full merging' of the branch. and in the case of such operation merge history (mergeinfo) gets corrupted. that's the reason why svn-book recommends to delete branch after reintegration. in other cases (not reintegration) simple merges between branches (specific revisions, for example) are encouraged. nothing bad will happen. You can check related question to make sure: http://stackoverflow.com/questions/877830/is-it-safe-to-use-a-subversion-feature-branch-after-reintegrate-merged-to-trunk – altern Jan 16 '12 at 14:37
  • Thanx for the ref to the question (although to my understanding, it doesn't explicitly talk about my main concern). I find svn docs rather ambiguous in this regard or perhaps it is obvious and I'm the one with ambiguity. All in all, the assurance from a colleague, like you, will do ;-) – Ashkan Kh. Nazary Jan 18 '12 at 06:40