David Glasser wrote:
> On Dec 6, 2007 10:26 AM, <cmpilato@tigris.org> wrote:
>> Author: cmpilato
>> Date: Thu Dec 6 10:26:12 2007
>> New Revision: 28303
>>
>> Log:
>> On the 'mo-betta-two-url-merges' branch, take a different approach to
>> the two-url merge problem. So, given a situation like this:
>>
>> +-----------> (A)
>> /
>> -----+-------------> (B)
>> (C)
>>
>> Say we wish to merge the diff between A and B to some target.
>>
>> Rather than do two mergeinfo-recording merges (A:C, C:B) like code in
>> the branch on which is branch is based does, we instead do one
>> mergeinfo-not-recording merge A:B, and then two record-only merges
>> (A:C, C:B).
>
> Hey, Mike! Is it just me, or is our old svn_client_merge_peg-only
> mergeinfo calculation now just a special case of your mo-betta-merge,
> where C is equal to A or B?
Yes. svn_client_merge_peg3 covers the case where A == C or B == C. We
could have svn_client_merge3() just call svn_client_merge_peg3() in those
cases, but I'm not sure it's worth it. We'd be reopening ra-sessions and
calculating repos roots and stuff all over again unnecessarily, and the code
overlap is super-minimal already.
Oh, I was thinking about this backwardsly. Are you asking if
svn_client_merge_peg3() should just become a wrapper around
svn_client_merge3()? It certainly could, but I'd had to do is-ancestral
checks all over again when we already know the sources are ancestrally
related (by virtue of coming in through the ..._peg3() interface).
Then again, maybe you were suggesting something else. Or maybe you were
suggesting nothing at all. Or maybe I'm just enjoying the typing practice
this mail affords me. Or...
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Dec 7 06:02:58 2007