I have read quite a bit about the need to re-integrate when you merge from a branch back to the trunk in SVN (an article about foreign repository merges was really helpful).
The problem seems to come from the fact that people are regularly updating the branch from the trunk which means that the final merge back is reflective.
In my use-case, we want to create a release branch which will live for as long as it takes to stabilise the branch and fix any bugs. To maintain stability we don't want to merge up from the trunk, but we do want to regularly merge fixes down from the release branch so that the trunk gets all the bug fixes for free. We also don't want to wait until the end of QA to merge back to trunk. We therefore want to:
- Create the branch
- Make regular changes to the branch (and trunk)
- Merge back to trunk regularly (daily perhaps)
Since we will never merge up from trunk, I don't think that we need to worry about the problems that re-intergrating is designed to fix. Is there a problem with this approach?
Your approach will work fine for your case.
The only problem with reflective merges is loosing the conflict resolution work (and unrelated changes committed during a merge). Since you won't have any conflicting changes, and all changesets on your branch will be legitimate candidates for merging into trunk, you're good to go.
If you start merging from trunk, then you might be in some trouble, but even then, if you've got minimal conflict resolution work and you keep track of it, you're still good to go.