Merges to targets with non-inheritable ranges, or subtrees with the same, don't work if the merge source and range being applied intersect with the non-inheritable mergeinfo. For example, say we merged to a target with switched subtrees and ended up with a slew of non-inheritable mergeinfo, something like this (from merge_tests.py 50): >svn st -v A_COPY 8 2 jrandom A_COPY 8 2 jrandom A_COPY\B 8 2 jrandom A_COPY\B\lambda 8 2 jrandom A_COPY\B\E 8 2 jrandom A_COPY\B\E\alpha 8 2 jrandom A_COPY\B\E\beta 8 2 jrandom A_COPY\B\F 8 2 jrandom A_COPY\mu 8 2 jrandom A_COPY\C 8 2 jrandom A_COPY\D 8 2 jrandom A_COPY\D\gamma S 8 2 jrandom A_COPY\D\G 8 2 jrandom A_COPY\D\G\pi S 8 2 jrandom A_COPY\D\G\rho 8 2 jrandom A_COPY\D\G\tau 8 2 jrandom A_COPY\D\H 8 2 jrandom A_COPY\D\H\chi 8 2 jrandom A_COPY\D\H\omega S 8 2 jrandom A_COPY\D\H\psi # No mergeinfo yet: >svn pl -vR A_COPY # Cherry harvest: >svn merge %url50%/A A_COPY --- Merging r3 through r8 into 'A_COPY\D\G': U A_COPY\D\G\rho --- Merging r2 through r8 into 'A_COPY\D\H': U A_COPY\D\H\psi U A_COPY\D\H\omega --- Merging r2 through r8 into 'A_COPY': U A_COPY\B\E\beta # Each switched path and it's siblings get explicit mergeinfo # describing the merge. The parent of each switched path # gets the same but with non-inheritable mergeinfo: >svn pl -vR A_COPY Properties on 'A_COPY': svn:mergeinfo : /A:2-8 Properties on 'A_COPY\D': svn:mergeinfo : /A/D:2-8* Properties on 'A_COPY\D\gamma': svn:mergeinfo : /A/D/gamma:2-8 Properties on 'A_COPY\D\G': svn:mergeinfo : /A/D/G:2-8* Properties on 'A_COPY\D\G\pi': svn:mergeinfo : /A/D/G/pi:2-8 Properties on 'A_COPY\D\G\rho': svn:mergeinfo : /A/D/G/rho:2-8 Properties on 'A_COPY\D\G\tau': svn:mergeinfo : /A/D/G/tau:2-8 Properties on 'A_COPY\D\H': svn:mergeinfo : /A/D/H:2-8* Properties on 'A_COPY\D\H\chi': svn:mergeinfo : /A/D/H/chi:2-8 Properties on 'A_COPY\D\H\omega': svn:mergeinfo : /A/D/H/omega:2-8 Properties on 'A_COPY\D\H\psi': svn:mergeinfo : /A/D/H/psi:2-8 >svn ci -m "" Sending A_COPY Sending A_COPY\B\E\beta Sending A_COPY\D Sending A_COPY\D\H Sending A_COPY\D\H\chi Sending A_COPY\D\H\omega Sending A_COPY\D\gamma Sending A_COPY\D\G Sending A_COPY\D\G\pi Sending A_COPY\D\G\tau Sending A_COPY\D\H\psi Sending A_COPY\D\G\rho Transmitting file data .... Committed revision 9. # Update before going on so no surprises with # inheritance or elision: >svn up U A_COPY_2\D\G\pi U A_COPY_2\D\G\tau U A_COPY_2\D\G UU A_COPY_2\D\H\psi UU A_COPY_3\D\G\rho Updated to revision 9. # Let's say we don't like all that explicit subtree # mergeinfo and want to revert the whole mess. If # we reverse merge r8:1 that should get rid of *all* # the explicit mergeinfo on A_COPY. It doesn't even # reverse merge everything, let alone set the # correct mergeinfo: >svn merge %url50%/A A_COPY -r8:1 --- Reverse-merging r8 through r2 into 'A_COPY': U A_COPY\B\E\beta >svn st A_COPY M A_COPY M A_COPY\B\E\beta M A_COPY\D M A_COPY\D\gamma M S A_COPY\D\G M A_COPY\D\G\pi M S A_COPY\D\G\rho M A_COPY\D\G\tau M A_COPY\D\H M A_COPY\D\H\chi M A_COPY\D\H\omega M S A_COPY\D\H\psi # Only beta is reverse-merged!?!? Paths either switched or # in a switched subtree, rho, omega, and psi, are not reverse # merged. Worse, the mergeinfo set looks like the full # reverse merge did occur, but we end up with empty mergeinfo # on the three switched paths: >svn pl -vR A_COPY Properties on 'A_COPY\D\G': svn:mergeinfo : Properties on 'A_COPY\D\G\rho': svn:mergeinfo : Properties on 'A_COPY\D\H\psi': svn:mergeinfo : This empty mergeinfo isn't overriding anything and really should elide. This is because of the way we limit elision within sections of a subtree: Merge target T has subtree S1 has subtree S2. We try to elide S1 to T, then S2 to S1 if it still exists or T otherwise. Then finally T to the repos. But if S2 is switched it can't elide up the WC so nothing happens. We probably need to make an exception for switched subtrees and attempt to elide them right to the repos as they are completely unrelated to the larger tree in terms of mergeinfo inheritance and elision. If we don't, we can get these cases where we merge a range, reverse merge the same range, but end up in a different state than we started. Note: This whole thing has me wondering if this restricted elision is even necessary now, I'll look into that after this issue is fixed, I'm *certain* there was a reason for this, but now I just don't see it...at any rate, it needs to be documented in the code or removed.