[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 15 Nov 2012 19:40:28 +0000 (GMT)

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

This is an archived mail posted to the Subversion Dev mailing list.