Search code examples
svntortoisesvnmergesvn-reintegrate

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?

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?

Solution

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