Prior to 1.5.5, the merge --reintegrate option would not work if the merge source had any subtree mergeinfo. In 1.5.5 (http://svn.apache.org/viewvc?view=revision&revision=874165) we made improvements that allowed reintegrate merges in that case so long as the subtree mergeinfo on the source reflected that the same ranges were previously merged from the target to the source across the entire source tree, e.g.: 1) Start with a /trunk with explicit subtree mergeino 2) copy /trunk to /branches/b1 3) Work continues on /trunk and /branches/b1 4) sync merge all available revisions from /trunk to /branches/b1 5) Reintegrate /branches/b1 back to /trunk. These improvements assumed that all the sync merging previously done to the branch was at the *root* of the branch and that all subtrees' mergeinfo was updated, regardless of whether the subtree was affected by the merge. In http://svn.apache.org/viewvc?view=revision&revision=878767 "unrelated" improvements were made such that when a merge is performed, only subtrees affected by the merge have their mergeinfo updated. This was not backported but will be part of 1.7. The reintegrate logic needs to take this new behavior into account. In the above use case in step 4, the sync merges no longer record mergeinfo on every subtree without exception; if the subtree is unaffected its mergeinfo is not altered. So when the reintegrate merge is attempted in step 5, an error will occur, because based strictly on the source's mergeinfo, it appears that the source is not completely synced up with the target. fyi, the error will look something like this: C:\SVN\trunk-wc>svn merge ^^/branches/feature-branch-3 . --reintegrate ..\..\..\subversion\svn\merge-cmd.c:358: (apr_err=195016) ..\..\..\subversion\libsvn_client\merge.c:9416: (apr_err=195016) svn: Reintegrate can only be used if revisions 40491 through 40561 were previously merged from svn:///S.T.O.MIRROR/trunk to the reintegrate source, but this is not the case: branches/feature-branch-3 Missing ranges: /trunk:40491-40493,40543-40544 branches/feature-branch-3/subversion Missing ranges: /trunk/subversion:40491-40492,40543-40544 branches/feature-branch-3/subversion/bindings/javahl Missing ranges: /trunk/subversion/bindings/javahl:40491-40492,40543 branches/feature-branch-3/subversion/svn Missing ranges: /trunk/subversion/svn:40491,40543-40544 branches/feature-branch-3/subversion/svn/conflict-callbacks.c Missing ranges: /trunk/subversion/svn/conflict-callbacks.c:40543-40544 branches/feature-branch-3/subversion/tests/cmdline/patch_tests.py Missing ranges: /trunk/subversion/tests/cmdline/patch_tests.py:40491-40492,40544 It would be desirable to improve the reintegrate logic so that it can determine if the "missing" sync merges are inoperative. If that is the case, it can safely allow the reintegrate merge to proceed. This will also allow the use case where all the "sync" merges are done as subtree merges, but effectively all the changes have been merged from trunk to the branch. If we don't do this, reintegrate will return to its pre 1.5.5 status of being largely useless when dealing with subtree mergeinfo. Users will be left only with the two-URL merge "workaround", which works perfectly well, but for better or worse, people like the simplicity that --reintegrate offers.