Is it safe to use a subversion feature branch after reintegrate-merged to trunk?

Question

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?

Update 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?

Answer 1

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.

Answer 2

Similar/duplicate of this one

Answer 3

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:

I don't think that this has changed in 1.6.

edit 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.

Answer 4

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.

Edit
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.