In r1336529 I fixed the symmetric merge code to work with merging changes into a file from its own history, and in r1336559 I adjusted the tests that depended on a simple merge producing conflicts that the symmetric merge will not produce. Now there are just these test failures:
FAIL: merge_tests.py 78: dont merge revs into a subtree that predate it FAIL: merge_tests.py 88: subtree merges dont cause spurious conflicts FAIL: merge_tests.py 89: target and subtrees need nonintersecting revs FAIL: merge_reintegrate_tests.py 10: merge --reintegrate with subtree mergeinfo - Julian ----- Original Message ----- > From: Branko Čibej <br...@apache.org> > To: dev@subversion.apache.org > Cc: > Sent: Thursday, 10 May 2012, 8:58 > Subject: Re: Symmetric merge -- current test failures when enabled > > On 10.05.2012 09:36, Julian Foad wrote: >> Branko Čibej wrote: >>> On 09.05.2012 18:54, Julian Foad wrote: >>>> The second group concerns merging changes into a file from its own > (past or >>> future) history; this kind of merge isn't a 'sync' so > shouldn't >>> be handled by this code path. >>> >>> We keep coming back to this ... I still don't understand /why/ we > would >>> need more than one merge algorithm, or why the symmetric merge would > not >>> work correctly in this case. >> Well, I was hand-waving a bit, meaning to dismiss this as some kind of > simple side-issue, which I think it is. I agree that, in principle, there > need > not be any other kind of merge. In practice, however, we might want to > bypass > the part of the algorithm that traverses the merge graph and branching > history > to find an appropriate base, if we have a degenerate case where we know in > advance what base to use, and if the source and target branches do not both > exist as separate branches in the repository. > > Ah, OK. I was worried a bit there. :) > > By the way ... the logical shortcut for "svn merge -rX:X-1 . ." would > be > "svn revert -cX", with the difference that such a reversion > doesn't > really need to change the mergeinfo, because it's really more like "svn > diff -c-X | svn patch". > > You probably don't want to enhance revert in this way, having your hand > full of the merge code, but I though I'd toss the idea here as long as > we're on the subject. :) > > -- Brane >
