Is it safe to use a subversion feature branch after reintegrate-merged to trunk?
Must a feature branch be deleted after it’s merged (reintegrated) back to trunk?
I prefer to constantly merge changes back and forth from my feature branch – I believe this keeps the conflicts to a minimum. Yet I understand that once you use the reintegrate merge to trunk, a feature branch should be deleted.
Is it so? Why? What can I do to circumvent this?
I’m asking about technical problems that come from the tool, not “methodology concerns”. I intend to keep working on the feature branch after the merge.
Update the top answer indeed specifies a rather complex procedure (merge, delete & rebranch). Is there an easy way to accomplish this in TortoiseSVN? Shouldn’t there be?
5 Solutions collect form web for “Is it safe to use a subversion feature branch after reintegrate-merged to trunk?”
edit: This problem appears to have been fixed in SVN 1.8. The section on basic merging from the SVN 1.8 book has been updated to say that it is OK to reuse a feature branch. The answer below is only relevant for older SVN versions.
From the section on basic merging in the svn book:
In Subversion 1.5, 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:
This is still the case in SVN 1.6 and 1.7.
This excellent article on reflective merges explains why exactly you can’t or shouldn’t recycle a feature branch. Summary of the most important points:
- you may do work to resolve conflicts
when reintegrating with the trunk
- The reintegration commit in trunk
therefore contains both changes
coming from the feature branch and
conflict resolution work
- However, subversion will not help you
merge this conflict resolution work
back to the feature branch. It simply
looks at the mergeinfo and thinks
“these changes originally came from
the feature branch, no need to merge
them again to their origin”.
Deleting the feature branch and rebranching is cheap and avoids this whole issue.
We do this often (SVN 1.5 and above). You just have to make sure not to remerge those changes back into the branch.
To do that simply do a range of revisions merge from the trunk to the branch. Specify the revision in the trunk that you did the reintegrate of the branch and mark it as “Only record the merge” from the trunk revision to the branch.
Once you do that you should be good to go.
The point the wcoenen brings up from the article about conflicts is valid. If you do not sync the trunk changes into the branch before doing the reintegrate you will have the conflict problem. We keep the branch synced up and have had no problem continuing to reuse the branch after multiple reintegrates.
Keeping a Reintegrated Branch Alive
There is an alternative to destroying and re-creating a branch after reintegration. To understand why it works you need to understand why the branch is initially unfit for further use after it has been reintegrated.
Yes, you can do a record-only merge to keep the branch alive.
See Keeping a reintegrated branch alive in the Subversion Book.
Subversion 1.8 allows you to merge repeatedly back and forth between two branches, whereas versions 1.7 and earlier did not. Read the release note here: http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate.
This all depends on your personal opinion, and on the number of people merging into trunk.
If you have a lot of people merging in, then it is probably better to only merge a branch once it is finished with, and then to delete it (you can always access it by going back to the last revision where it existed). If you try to continuously merge in this situation you will just confuse yourself.
However, if you don’t have many sub-branches, and you are using subversion 1.5+, you can get away with this, and it can help to avoid merge conficts.
Of course, if your “trunk” is used as a beta/release candidate/release repository, then you sholdn’t do this.