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
