Issue #4258 Automatic merge after subtree merge in opposite direction [was: Symmetric merge and subtrees]

[Julian Foad <ju...@btopenworld.com>]

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