Mastering Subversion’s Reintegrate Merge: A Practical Guide

Problem: Long‑Lived Feature Branches Spiral

When a feature branch lives for weeks or months, it often diverges from trunk as new commits arrive on trunk. Developers then face two headaches: a flood of merge conflicts and a messy commit history that makes it hard to track what changes actually landed in trunk.

Without a clear reintegration strategy, teams end up performing ad‑hoc merges, losing the chronological record of work, or inadvertently reapplying code changes.

The Solution: svn merge --reintegrate

Subversion 1.5+ introduced the --reintegrate flag to the svn merge command. It tells SVN that the working copy you are merging into is a clean copy of trunk, and that the branch you are merging from is a feature branch that has been fully developed but not yet merged back.

Key benefits:

• Preserves the original commit history of the branch.
• Minimizes conflict resolution by applying the branch’s net change set.
• Creates a single, clean merge commit in trunk.

Step‑by‑Step Example

1. Set up a test repository
   

   # Create a repository
   svnadmin create /tmp/svnrepo
   # Set up a working copy of trunk
   svn checkout file:///tmp/svnrepo/trunk wc_trunk
   # Add initial content
   cd wc_trunk
   mkdir src
   printf "# Initial file" > src/main.c
   svn add src/main.c
   svn commit -m "Initial commit"
   

2. Create a feature branch
   

   svn copy ^/trunk ^/branches/featureX -m "Start featureX"
   

3. Work on the branch
   

   svn checkout ^/branches/featureX wc_feature
   cd wc_feature
   # Make several commits
   printf "# Feature code" > src/feature.c
   svn add src/feature.c
   svn commit -m "Add feature file"
   # Simulate further changes
   printf "// TODO" >> src/main.c
   svn commit -m "Update main for feature"
   

4. Update trunk with new changes
   

   cd wc_trunk
   printf "// Trunk update" >> src/main.c
   svn commit -m "Trunk update while feature in progress"
   

5. Reintegrate from the branch
   

   # Ensure trunk working copy is clean
   svn status
   # Perform reintegration
   svn merge --reintegrate ^/branches/featureX
   # Resolve any remaining conflicts (if any)
   svn status
   # Commit the merge
   svn commit -m "Reintegrate featureX into trunk"
   

6. Verify merge success
   

   # Check mergeinfo
   svn mergeinfo ^/branches/featureX
   # Verify no pending changes
   svn status
   # Inspect log for a single merge commit
   svn log -v
   

7. Delete the branch
   

   svn delete ^/branches/featureX -m "Remove featureX after reintegration"
   

Trade‑offs and Limitations

• Prerequisites: The branch must not have been merged into trunk before. If you have already merged parts of the branch, --reintegrate may produce duplicate history or errors.
• Single‑use: After a reintegration, the branch should be deleted or frozen. Continuing to commit to it without resetting its merge history will force complex merge scenarios.
• Version requirement: --reintegrate is available only in Subversion 1.5 and later. Verify your client with svn --version.
• Conflict risk: If trunk has advanced significantly since branching, you may still face conflicts during reintegration. Resolve them carefully; the merge commit should reflect the final state.

Practical Verification Checklist

1. Run svn mergeinfo ^/branches/featureX and confirm that it lists the branch as merged.
2. Execute svn status in trunk; it should report no pending changes.
3. Use svn log -v to see a single merge commit that references the branch.
4. Attempt to delete the branch with svn delete ^/branches/featureX and confirm that no mergeinfo warnings appear.

Actionable Takeaway

Adopt a short‑lived branch workflow: create the branch, develop, reintegrate with --reintegrate, commit, and delete the branch. This keeps history clean, reduces conflict churn, and ensures that trunk always reflects a linear, understandable commit history.

When you encounter a branch that has already been partially merged, skip --reintegrate and perform a regular merge instead. Document the merge history in commit messages to avoid confusion later.