[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r28303 - in branches/mo-betta-two-url-merges/subversion: libsvn_client tests/cmdline

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-12-07 06:02:30 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.