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
>
Received on 2012-07-24 19:40:49 CEST