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
Received on 2012-07-10 18:16:24 CEST