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.

  • Merge two Git repos and keep the history
  • git merge: is there a way to force --squash?
  • Merge/Branch Strategy
  • Pushing updates to a pruned Mercurial branch
  • What is the default behaviour of “Resolve using theirs” in git
  • How to copy files with their history among different git repositories?
  • 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?

  • Subversion Update Issue
  • obtaining full file paths in git merge
  • svn:external in git
  • Include SVN revision number in source code
  • How to achieve `git --no-ff --ff-only` which is not allowed
  • Deploying CodeIgniter (or any PHP projects) to the live site?
  • 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.

    Edit 2

    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:

    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.

    Git Baby is a git and github fan, let's start git clone.