Known Issues

There are still known issues with merge tracking in 1.5.0. We’re working on the most important ones first, which are:

• issue #3128: merge --reintegrate should handle renames better
• issue #2897: proper support for reflective merges
• issue #3126: better change-availability reporting (svn mergeinfo shows too few or too many eligible revisions)
• issue #2837: allow merge tracking to be useful when performing cyclic merging
• issue #3056: avoid repeat merge in an intelligent way
• issue #2898: handle mergeinfo when deleting/adding children you don’t have access to
• issue #3067: subtrees that don’t exist at the start or end of a merge range shouldn’t break the merge
• issue #3157: merging a change from a path’s natural history creates self-referential mergeinfo
• issue #3174: merge algorithm chokes on subtrees needing special attention that have been renamed

(See also the list of all merge-related open issues, though note that not all of them are about merge-tracking and many predate it.)

Issue #3157 is particularly easy to run into, so here’s a more detailed explanation of what the issue is and how to work around it:

Merge tracking information currently can include the “natural history” of a path. One situation where this happens is when creating a branch from trunk at a certain revision X and later merging all changes from branch back to trunk, without explicitly limiting the merge range and without using the --reintegrate option. Afterwards, the merge tracking information on trunk will list revisions before X. This does no harm to future merge operations, but thereafter svn log -g on trunk will report these revisions from the “natural history”, which is typically not expected. This is because svn log -g uses the merge tracking information from previous revisions (not only from HEAD).

Note that this should not be a problem with release branches (also called “maintenance branches”), because one typically does not merge them back to trunk. Instead, recommended practice is for new changes to enter on trunk and be ported outward to the branches that need the changes. However, you could run into this problem with a feature branch, which would be merged back to trunk once, at the end of the branch’s lifetime.

One workaround is to correct the merge tracking information before committing the merged revision, by reverse merging the “natural history” information: svn merge --record-only -rX:1. Another solution is to avoid this situation entirely, by explicitly specifying merge ranges in the first place, e.g.: -rX:HEAD. See this mail for more information.

When merging a feature branch, the best solution is to use the --reintegrate option; then this problem won’t happen in the first place.