Re: Symmetric merge and subtrees
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 18 Jul 2012 22:38:48 +0100 (BST)
Investigating the second of three 'symmetric merge' test failures:
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*
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 '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':
For completeness, let's see what a plain 1.7 merge does:
--- Merging r2 through r15 into '[...]/A':
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 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.
 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).
This is an archived mail posted to the Subversion Dev mailing list.