svn:mergeinfo Bloat After Subdirectory Merges in Subversion 1.8: Consolidate or Leave It?

Question

Our repository has been on Subversion 1.5+ merge tracking for years, and repeated merges at the subdirectory level have left many files and folders carrying their own svn:mergeinfo properties. The project is now standardizing on the 1.8 client behavior, and I want to define a policy for handling this accumulated metadata going forward.

The concern is that scattered mergeinfo on child paths appears to complicate later merges and occasionally surfaces conflicts that seem unrelated to the actual changes being merged. At the same time, I understand that manually editing or deleting svn:mergeinfo can break merge tracking and produce inconsistent results, so I am hesitant to clean it up blindly. Assume a single repository with feature branches merged back into trunk, clients on 1.8 or later.

Does consolidating mergeinfo at the branch root (rather than leaving it on subdirectories) change the outcome of subsequent merges, or is it purely cosmetic? Is there a documented safe boundary for when elision happens automatically versus when manual intervention is required? Should a team policy forbid subtree merges entirely to prevent further bloat?

Tasadduq Burney · Answer

Direct answerConsolidating svn:mergeinfo at the branch root does not change the outcome of subsequent merges in Subversion 1.8; it is functionally cosmetic if the repository structure remains consistent. The 1.8 merge algorithm unions declared ranges across all ancestor paths, so whether mergeinfo resides on a subdirectory or the root, the intersecting ranges are resolved identically.Likely explanation versus confirmed factScattered mergeinfo on child paths does not block later merges, but overlapping range reports can appear as unrelated conflicts.Subversion 1.8 does not automatically elide mergeinfo from subdirectories; cleanup requires explicit operations.Blind deletion of svn:mergeinfo risks breaking merge tracking history and can cause duplicate edits or unexpected conflict markers.Is a policy forbidding subtree merges necessary? It prevents further bloat, but is unnecessary if the team enforces explicit source tracking and periodic mergeinfo audits.Verification stepssvn merge --dry-run on the feature branch before and after consolidating mergeinfo to diff the predicted merge sets and confirm no unexpected changes.svn propget svn:mergeinfo ^/branches/feature and svn propget svn:mergeinfo ^/branches/feature/subdir to compare range coverage and verify that root-level mergeinfo subsumes subdirectory entries.Create a temporary branch, merge a known set of revisions, then consolidate with svn merge --record-only and verify with svn mergeinfo that ranges are correctly unified.If your repository uses subtree merges rather than standard branch‑into‑trunk merges, the accumulation rate will be higher. Confirming that detail will help tailor the policy.

svn:mergeinfo Bloat After Subdirectory Merges in Subversion 1.8: Consolidate or Leave It?

1 answer

Direct answer

Likely explanation versus confirmed fact

Verification steps

Your perspective belongs here.

0 question comments