Merge Tracking in Subversion: Making Branch‑to‑Trunk Workflows Reliable

The Problem: Repeated Branch‑to‑Trunk Merges Become a Maintenance Nightmare

When you create a feature branch, work on it, merge it back to trunk, and then keep the branch alive for additional changes, you’re doing a lot of the same work over and over. Without a clear record of what revisions have already been integrated, the next merge may re‑apply changes you already committed, or worse, drop a conflict that should have been resolved. The result is a cluttered history and a higher risk of regressions.

Thesis: svn:mergeinfo Is the Key to Practical Branching

Subversion 1.5 introduced merge tracking. The svn:mergeinfo property, stored on directories, records the exact revision ranges that have moved between two paths. When a client performs a merge, it consults this property and automatically skips revisions that are already present, making repeated merges safe and idempotent.

How svn:mergeinfo Works Under the Hood

The property is a plain text string that looks like this on a directory that has received changes from a branch called /branches/feature-x:

svn:mergeinfo: /branches/feature-x:100-150

Key points to know:

• Inherited metadata – A child directory may not have its own svn:mergeinfo entry, yet the merge history is still visible when you query the parent. Inspecting only the leaf can mislead you about what has been merged.
• Mergeinfo can appear on unrelated paths after copies or moves, producing “phantom” merges. Always run a dry run before committing.
• Mergeinfo is not a graph; it only records ranges. Independent, content‑equivalent changes made on two branches are not automatically reconciled.

Concrete Example: Short‑Lived Feature Branch with Frequent Syncs

Below is a step‑by‑step workflow that demonstrates how merge tracking keeps a feature branch current and cleanly reintegrates it. The example assumes you have a repository http://svn.example.com/repo and a working copy of trunk checked out locally.

1. Create the branch from trunk:

   svn copy http://svn.example.com/repo/trunk \
             http://svn.example.com/repo/branches/feature-x \
             -m "Create feature-x branch"
   

2. Check out the branch locally:

   svn checkout http://svn.example.com/repo/branches/feature-x feature-x
   

3. Sync from trunk while working on the branch to avoid diverging too far:

   cd feature-x
   svn merge http://svn.example.com/repo/trunk
   svn commit -m "Sync trunk into feature-x"
   

4. Repeat syncing as needed throughout development. Each merge will skip revisions already merged because the svn:mergeinfo on the branch records what came from trunk.
5. Reintegrate back to trunk when finished:

   cd ../trunk
   svn merge http://svn.example.com/repo/branches/feature-x
   svn commit -m "Reintegrate feature-x into trunk"
   

   Modern clients detect that the branch is the source of the merge and apply the appropriate mergeinfo automatically. Older clients required the --reintegrate flag, but that is no longer necessary in Subversion 1.7+.

Verification Checklist

• Check client and server versions – run svn --version on both ends. Merge tracking requires 1.5 or newer.
• Dry run before committing – svn merge --dry-run http://svn.example.com/repo/trunk shows only new revisions that haven’t been merged yet.
• Inspect mergeinfo – svn propget svn:mergeinfo -R in both trunk and branch directories. You should see the same revision ranges recorded on the opposite side.
• Record-only merges – if a change was applied by a patch on a different branch, use svn merge --record-only -c 1234 http://svn.example.com/repo/trunk to mark revision 1234 as merged without changing file content.

Trade‑offs and Limitations

Merge tracking simplifies short‑lived branches, but it’s not a silver bullet:

• Long‑lived branches accrue large svn:mergeinfo entries, making merges slower and the history harder to read.
• Cherry‑picking individual revisions expands the property file, potentially cluttering the working copy.
• Because mergeinfo tracks revision ranges, it does not detect content‑equivalent changes made independently on two branches; you may still need to resolve conflicts manually.

Practical Decision: When to Branch vs. Trunk‑Only Development

If your team’s workflow involves many parallel feature streams or long release cycles, merge tracking makes branch maintenance manageable. However, if most work happens in a single global revision space and you rarely need isolation, a trunk‑only strategy keeps history flat and eliminates the need to manage mergeinfo altogether.

Actionable Closing

To decide whether merge tracking fits your project:

1. Audit your current branch lifespan. Are you keeping branches open for weeks or months?
2. Run svn propget svn:mergeinfo -R on a sample branch to see the size of the property.
3. Try the dry‑run workflow above on a throwaway repository. If the merge skips already applied revisions and the history stays clean, you’re ready to adopt merge tracking.
4. Document the process in your team's contribution guide, including the recommended use of --record-only for backports.

With these steps, you can turn repeated branch‑to‑trunk merges from a maintenance burden into a predictable, low‑risk operation.