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?

Improve this question
1
  • I for one don't reintegrate at all. Upon studying various branching strategies 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, 2012 at 12:56

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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, 2012 at 4: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. Beyond that, how would you handle bugs that are found in the rest of the project?
    – Caleb
    Apr 30, 2012 at 4:39
  • So, which do you prefer for bug fix, re-creating branch or keeping a reintegrated branch alive?
    – Sanghyun Lee
    May 3, 2012 at 1: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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.