Re: Subtree mergeinfo -- what I learnt at the Hackathon

I think the essence of this line of thought is:

We set up all of the possible mergeinfo scenarios, and we see what 'merge' does, and we see what 1.7 'merge --reintegrate' does, and we debate what cases are 'supported' versus knowingly 'unsupported', and we see what an ideal symmetric merge would do.  Then we evaluate the current 'symmetric'[1] implementation against that: does it do "the same as" or "better than" or "worse than" what a user can do with the existing merge (assuming he/she chooses the "reintegrate" option appropriately).

It's not easy to set up all of the possible scenarios: reintegrating the root but excluding a subtree, for example, can't be done in a single merge command.  Does that mean that scenario is uninteresting?  No, I don't think so.  What we can do is eliminate the existing merge command from the set-up phases of the test scenarios, and set up the desired mergeinfo directly: "faking it", if you will.  Doing it that way separates the concerns: the question of what the merge command will do, given a certain scenario, is a separate question from how we can use merges to create that scenario.

The question I have at the moment is: Does this approach to evaluation make sense to you?

 
[1] 'symmetric' -- Urgh! -- we must change the name as the current incarnation is not very symmetric at all.

- Julian

--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
----- Original Message -----
> From: Julian Foad <julianfoad_at_btopenworld.com>
> To: Paul Burba <ptburba_at_gmail.com>
> Cc: Subversion Development <dev_at_subversion.apache.org>; C. Michael Pilato <cmpilato_at_collab.net>; Branko Čibej <brane_at_apache.org>; Stefan Sperling <stsp_at_elego.de>
> Sent: Tuesday, 10 July 2012, 12:15
> Subject: Re: Subtree mergeinfo -- what I learnt at the Hackathon
> 
> Hi Paul.  Thanks for your comments.
> 
> Paul Burba wrote:
> 
>>  On Mon, Jul 9, 2012 at 4:16 PM, Julian Foad wrote:
> [...]
>>>     * The merging history of the root 'R' (the root node of the 
>>>  requested merge source and target trees), and of a subtree 'S' 
> (a
>>>  single  node or subtree
>> 
>>  Minor point: I've always considered a single node as a subtree as far
>>  as mergetracking goes; so file merges are "subtree merges". I 
> mention
>>  this only because most of the code and testing comments I've written
>>  over the years assume this.  Again, it's a minor point, but AFAICT we
>>  can largely ignore the node type for this level of conversation.
> 
> Agreed; my parenthesis was meant to clarify this.
> 
>>>   whose merging history differs from that of the root node in a 
> significant 
>>>  way).
>> 
>>  You might want to define this a bit more explicitly.  I'm pretty sure
>>  I know what you mean, but it might not be clear to others.  Something
>>  like: "Mergeinfo[1] differences between the root and the subtree, if
>>  they exist, describe revisions that are inoperative on both the root
>>  and the subtree".
> 
> Yes, something like that.
> 
>>  [1] "Mergeinfo" interpreted here in the most general way, 
> including
>>  explicit mergeinfo, inherited mergeinfo, and implicit mergeinfo (i.e.
>>  natural history).
> 
> [...]
>>>   CATEGORIZING SUBTREE MERGES: 1.7 Non-Reintegrate
>>> 
>>>   These cases are for a reintegrate merge A->B.
>> 
>>  A bit confused, the category is "1.7 Non-Reintegrate" but the 
> cases
>>  are for a reintegrate merge A->B?  Could you clarify?
> 
> Sorry, typo: I meant "These cases are for a non-reintegrate merge 
> A->B."
> 
>>  For example,
>>  given row 3 below, are we talking about the third merge here:
>> 
>>  A--------------------------->
>>    \            ^     \
>>  subtree      /       \
>>    merge    subtree     ?
>>       \     merge        \
>>        V    /             V
>>  B--------------------------->
> 
> Yes, that.
> 
>>  or here?
>> 
>>  A--------------------------->
>>    \            ^       ^
>>  subtree      /       /
>>    merge    subtree   ?
>>       \     merge    /
>>        V    /       /
>>  B--------------------------->
> 
> Not that.
> 
>>>   In each row of this table, up to two Root merges are indicated, and 
> their 
>>>  relative ordering is significant; similarly for Subtree merges.  The 
> ordering of 
>>>  R merges relative to S merges is not significant.
>>> 
>>>       Root     | Subtree   | Behaviour
>>>       ---------+-----------+-----------------------------------
>>>    1. never    | same      | OK (not a subtree scenario)
>>>                +-----------+-----------------------------------
>>>    2.          | [S<] S>   | Merge all needed changes
>>>                +-----------+-----------------------------------
>>>    3.          | [S>] S<   | All needed; & some duplicates in 
> S
>>>       ---------+-----------+-----------------------------------
>>>    4. [R<] R>  | same      | OK (not a subtree scenario)
>>>                +-----------+-----------------------------------
>>>    5.          | never     | Merge all needed changes
>>>    6.          | [S<] S> * |
>>>                +-----------+-----------------------------------
>>>    7.          | [S>] S<   | All needed; & some duplicates in 
> S
>>>       ---------+-----------+-----------------------------------
>>>    8. [R>] R<  | same      | All needed; & some duplicates in 
> R
>>>                |           | (not a subtree scenario)
>>>                +-----------+-----------------------------------
>>>    9.          | none      | All needed; & some duplicates in R
>> 
>>  "none" is the same as "never" in the key right?
> 
> Yes; sorry, just another typo.
> 
>>>   10.          | [S<] S>   |
>>>                +-----------+-----------------------------------
>>>   11.          | [S>] S< * | All needed; & some duplicates in 
> R and S
>>>       ---------+-----------+-----------------------------------
>>> 
>>>   Key:
>>>     *      -- S> not at same revision as R>, or S< not same as 
> R<.
>>>     R>     -- last complete Root merge in direction A->B.
>>>     R<     -- last complete Root merge in direction B->A.
>>>     never  -- never been merged in either direction since the YCA of A 
> and B.
>>>     [S<]   -- shorthand for both of the cases: no 'S<' 
> merge and an 'S<' merge.
>> 
>>  To clarify, do you mean "shorthand for *EITHER* of these cases: no
>>  'S<' merge *OR* an 'S<' merge." right?
> 
> Yes, if you like.  The row expands to two cases: one with no 'S<' in 
> this position, another with 'S<' in this position.  So this row:
> 
>   3.          | [S>] S<   | All needed; & some duplicates in S
> 
> expands to the following two cases:
> 
>   3a.         |      S<   | All needed; & some duplicates in S
> 
> (that is, subtree was never merged from A to B, but was merged from B to A)
> 
>   3b.         |  S>  S<   | All needed; & some duplicates in S
> 
> (that is, the last time the subtree was merged in the A to B direction was 
> before the last time it was merged in the B to A direction).
> 
>>  Either the last complete merge
>>  of the subtree was in the A->B direction or it was in the B->A
>>  direction.
> 
> No, I don't think that describes it.
> 
>> 
>>>     duplicates -- changes that are already present in the target.
>>> 
>>>   Example:  Row 9 represents the case where the Root's last complete 
> 
>>  merge was in the B->A direction, and its last complete A->B merge was 
> 
>>  earlier or never; and the Subtree likewise.  The root's last complete 
> merge 
>>  was before or after but not the same as the subtree's.
>> 
>>  But the last subtree in row 9 is listed as "none"?  Did you mean 
> row 
>>  11?
> 
> Sigh, yes, you're right and I'm confusing.  (I edited the table after 
> writing that.)
> 
>>  I'll hold off on further comments/questions until I get the above 
> straight.
> 
> Thanks.
> - Julian
>