5

From SVN 1.5, it supports reintegrate feature. I wonder when I should reintegrate. Should it be done before release or after release?

If I do it

Before release

  • Pro: It is not forgettable to merge with trunk.
  • Con: Merged version can be different from QAed version.

After release

  • Pro: Releasing version is same with QAed version.
  • Con: Some feature from trunk can be missed.

So, when do you reintegrate?

gnat
  • 21,442
  • 29
  • 112
  • 288
Sanghyun Lee
  • 829
  • 1
  • 7
  • 20
  • I for one **don't reintegrate at all**. Upon [studying various branching strategies](http://programmers.stackexchange.com/a/108298/31260 "there are plenty, you know...") and experimenting with some of these, our team opted for one that doesn't involve merging. And have been happy ever since. Per our measurements, efforts wasted on messing with svn dropped from 5 to 0.5 h / week per developer (about 1 day a week freed for real work, every week for every guy) – gnat Apr 30 '12 at 12:56

2 Answers2

4

Specific practices for using version control may differ from one organization to another, but the idea behind a feature branch is that it's a place where you can work on some feature of the overall project. If you want that code to make it into a given release, you'd better merge the code back to trunk (or whatever branch you use as a main development branch) before you do a release. The --reintegrate option that you're asking about is a signal to svn that it should ignore the changes that have been made to your branch as a result of merges from the main branch or trunk.

So, merge (with --reintegrate) when your feature is done and ready for testing.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • But if I reintegrate it before testing, I should fix bugs on trunk. And if testing process lasts for long time, trunk will be unstable for long time. Is it okay? – Sanghyun Lee Apr 30 '12 at 04:24
  • 1
    @Sangdol Keep reading beyond the section of the Subversion Book that you linked. A little further down is the advice: *...if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk...* And beyond that is a section that tells you how to continue using the same branch without destroying it: [*Keeping a Reintegrated Branch Alive*](http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice). Beyond that, how would you handle bugs that are found in the rest of the project? – Caleb Apr 30 '12 at 04:39
  • So, which do you prefer for bug fix, re-creating branch or keeping a reintegrated branch alive? – Sanghyun Lee May 03 '12 at 01:00
1

always reintegrate before release. You then get a chance to test and find your bugs, and if there are any, you can either fix them on trunk, or create a new branch to fix the bugs before reintegrating them and repeating the release procedure all over again.

This is the way you should do it - its repeatable, and you know exactly where you are at each step of the way. You can always reproduce what you have, easily.

Merging the branch after release means you have released 'beta' code. If you ever want to revert to the released software some point in the future, you will find it difficult to get an exact copy.

You will never get the QAd version different from the release version - as the QA team will only ever work with the version that you've delivered to them, ie the one you've just merged into trunk.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172