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
Received on 2012-11-15 20:41:03 CET