I (Julian Foad) wrote: > 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).
I've fixed this in r1365182 by making the 'reintegrate-like' code path of symmetric merge call the 'find_reintegrate_merge' function which rejects cases such as this one (where a revision from the common ancestry of the two branches is not recorded as merged in the source branch). - Julian > # 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 >
