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
  • 20,543
  • 29
  • 115
  • 306
Sanghyun Lee
  • 839

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
  • 39,298
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,749
  • 7
  • 106
  • 173