(Just finishing an unfinished sentence...)
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>> This is great. You're right, the main thing seems to be that
>> find_symmetric_merge is currently only fetching and analyzing
>> the branch-root mergeinfo. It needs to fetch and analyze all
>> mergeinfo on the branch, finding a merge base for each subtree,
>> and proceed something like this:
>>
>> * If every base found is on the source branch:
>> -> choose the oldest base, and
>> -> pass this base to the "sync merge" code path.
>
> As an interim measure, r1349322 passes the YCA as the "source-left"
> location, every time it does a sync-style merge. This makes it find and merge
> any subtrees that need revisions merged, even revisions before the merge-root
> path's base, and so fixes two of the four tests that were failing.
>
> To do the rest of this, we need to
>
> (a) Upgrade the base-finding code to find the base for every subtree, not just
> for the merge-root path.
>
> (b) Write logic that separates these three cases (the three "*"
> bullet points in the quoted text here).
>
> (c) Write
... error reporting code that describes the problem understandably for human consumption, that perhaps suggest what to do next, like reintegrate already does in some cases.
- Julian
>> * If the same base is found for all subtrees
>> and this base is on the target branch:
>> -> pass this base to the "reintegrate" code path.
>>
>> * If different bases are found for different subtrees
>> and any base is on the target branch:
>> -> complain like "reintegrate" does in 1.7.
>
>
> Actually, existing 1.7 "sync" and "reintegrate" don't
> complain about all such cases: a "sync" simply ignores subtree
> mergeinfo in the opposite direction from the merge, and "reintegrate"
> simply ignores subtree mergeinfo in the same direction as the merge. We
> probably want to error out, reporting the reason, in those cases too; I'll
> write about that in a separate email.
>
>
> - Julian
Received on 2012-06-12 16:03:08 CEST