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

svn tortoisesvn merge svn-reintegrate
ripper234 picture ripper234 · May 18, 2009 · Viewed 7.2k times · Source

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

Wim Coenen picture Wim Coenen · May 18, 2009

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.

Related questions

Using TortoiseSVN how do I merge changes from the trunk to a branch and vice versa?

I've been reading up on branching/merging with Subversion 1.5 using the excellent and free Version Control with Subversion book. I think that I understand how to use the Subversion command line client to perform the actions that I need most …

Read More
Remove unnecessary svn:mergeinfo properties

When I merge stuff in my repository Subversion wants to add/change a lot of svn:mergeinfo properties to files that are totally unrelated to the things that I want to merge. Questions about this behaviour have been asked before …

Read More
SVN Mergeinfo properties on paths other than the working copy root

I have an SVN repository where I have trunk and a branch. I intend to merge the trunk into the branch at regular intervals, however, when I do this I see many property status changes, in addition to actual file …

Read More