Paul Burba wrote on 2012-11-02: > Julian Foad wrote: >> Paul Burba wrote:
>>> Julian Foad wrote: >>>> The following example is adapted from >>>> merge_symmetric_tests.py 18, subtree_to_and_fro(), >>>> "reintegrate considers source subtree mergeinfo": >>>> >>>> reintegrate 'everything' >>>> | >>>> A------o-s--------------x >>>> \ \ / >>>> \ \ / >>>> B o-----s----s----s--- >>>> | >>>> merge the subtree 'D' only [...] >>>> In terms of commands (assume a commit after each step): >>>> >>>> svn cp A B >>>> edit A >>>> edit A/D >>>> edit B/D svn merge ^/A/D B/D >>>> edit B/D >>>> svn merge --reintegrate ^/B A >>>> >>>> The output from "merge --reintegrate" is: >>>> >>>> svn: E195016: Reintegrate can only be used if >>>> revisions 2 through 8 were previously merged [...] [...] >>>> Is the symmetric merge 'broken'? This test claims so, on >>>> the basis of expecting it to behave like a reintegrate merge. >>>> However, we can't be strictly backward-compatible with both >>>> the reintegrate and the non-reintegrate behaviours if we have >>>> to pick one, because they differ. >>>> What do we want to see here? >>>> >>>> I think it depends what the user is thinking. If the user >>>> is thinking "just help me merge everything that needs to be >>>> merged", then the user probably would have used the plain >>>> 'merge' command in 1.7, and would prefer a wrong merge with >>>> spurious conflicts, given that we haven't yet implemented a >>>> correct merge. If the user is thinking "this is a >>>> reintegration, and I believe my branch was sync'd with the >>>> trunk recently", then the user probably would prefer this >>>> merge to bail out like 'reintegrate' does. [...] >>>> Our options for what 'symmetric' merge will do, in cases >>>> like this [1], are: >>>> >>>> (1) Implement correct merging. >>>> (2) Merge wrongly, with spurious conflicts, like plain >>>> 1.7 'merge'. >>>> (2a) (2) by default, with an option to check and bail out >>>> like (3). >>>> (3) Bail out like 1.7 'reintegrate'. >>>> (3a) (3) by default, with an option to force the merge to >>>> proceed like (2). [...] >>> I take your points about user intent but if the symmetric merge >>> code is meant to do away with the --reintegrate option, I think >>> we should take the more cautious approach and assume the user >>> intends a reintegrate, so IMO (3a) is the best choice. >> >> OK, yes. If I can try to interpret your meaning without saying >> "reintegrate", it would be: we should take the more cautious >> approach which is to bail out because of the inconsistent subtree >> state. The rule would be, for a request to merge in the direction >> A->B, roughly speaking: >> >> * if every node in the tree was last merged A->B or not at all >> -> merge in the non-reintegrate style >> >> * if every node in the tree was last merged B->A, up to the >> same B revision >> -> merge in the reintegrate style >> >> * otherwise >> -> bail out and report the subtree inconsistency >> >> I'll try to formulate that rule more precisely. > > Did you ever look into this any further? > > I'm going over the XFailing tests to determine what is considered a > 1.8 blocker and merge_automatic_tests.py 18: 'reintegrate considers > source subtree mergeinfo' is obviously still set to XFail. I have filed issue #4258 "Automatic merge after subtree merge in opposite direction" and marked the test accordingly. I classified it as a defect because of your feeling that it's a regression, but I really feel it's an enhancement. I set the milestone as 1.8-consider. - Julian
