Investigating the second of three 'symmetric merge' test failures: merge_reintegrate_tests.py 10
There is a definite issue concerning reverse merges from the branches' own history. In this test, the merge that behaves unexpectedly is the final 'reintegrate' shown in the following graph (which appears as a comment in that test). # Make some more changes to A_COPY so that the same revisions have *not* # been uniformly applied from A to A_COPY. In this case the reintegrate # merge should fail, but should provide a helpful message as to where the # problems are. # # A_COPY_3 4-------[9]-- # / \ # / \ [-8]___ # A -1---------5-6-7-8---10----------------\-------WC-- # \ \ (D) \ \ /reint. # \ \ (mu) \ \ / # A_COPY 2-\--------------------12---13--14--15-------- # \ / (D) # \ / # A_COPY_2 3-------------[11]-- A 'reintegrate' merge complains: svn: E195016: Reintegrate can only be used if revisions 2 through 15 were previously merged from [...]/A to the reintegrate source, but this is not the case: A_COPY/D Missing ranges: /A/D:8 A 'symmetric' merge merges every change made on the branch A_COPY onto branch 'A'. That includes r15, the removal of change A:8, which was a change to A/D/H/omega: --- Merging differences between repository URLs into '[...]/A': U [...]/A/B/E/alpha UU [...]/A/mu U [...]/A/D/H/omega U [...]/A/D --- Recording mergeinfo for merge between repository URLs into '[...]/A': U [...]/A U [...]/A/D G [...]/A/mu For completeness, let's see what a plain 1.7 merge does: --- Merging r2 through r15 into '[...]/A': U [...]/A/B/E/alpha UU [...]/A/mu --- Merging r2 through r15 into '[...]/A/D': G [...]/A/D --- Recording mergeinfo for merge of r2 through r15 [...] The plain merge does in fact merge r15, the reverse merge of r8. (It doesn't print any evidence of it there, because the result is a no-op, but if we change the test to make another modification to that file, then we can see it.) The root issue here is that a reverse-merge of a change from the shared history[1] history is interpreted by 'reintegrate' as a user error to be diagnosed, by plain 'merge' as just another change to be merged, and by the current 'symmetric' code as just another change to be merged. Without going into *why* they should behave differently right now, I think it is clear that the 'symmetric' merge should in this case behave like the 'reintegrate' merge and detect and report the situation. So I'll take a stab at fixing that. [1] We probably have very similar issues dealing with a reverse-merge of a change from the history of one branch or the other (after their youngest common ancestor). - Julian
