CODEWITHSUNDEEP
svntortoisesvnmergesvn-reintegrate
ripper234
ripper234

Reputation: 230386

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?

Upvotes: 22

Views: 7391

Answers (5)

Wim Coenen
Wim Coenen

Reputation: 66793

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.

Upvotes: 26

julian
julian

Reputation: 31

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.

Upvotes: 3

Tom Hubbard
Tom Hubbard

Reputation: 16139

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.

Edit 2

Keeping a Reintegrated Branch Alive (http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html)

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.

Upvotes: 9

Eugene Yarmash
Eugene Yarmash

Reputation: 150188

Yes, you can do a record-only merge to keep the branch alive.

See Keeping a reintegrated branch alive in the Subversion Book.

Upvotes: 4

jwoolard
jwoolard

Reputation: 6294

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.

Upvotes: -1

Related Questions