You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/12/07 01:46:45 UTC
Re: svn commit: r28303 - in branches/mo-betta-two-url-merges/subversion: libsvn_client tests/cmdline
On Dec 6, 2007 10:26 AM, <cm...@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?
(And if so, perhaps we can simplify the implementation based on that.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r28303 - in branches/mo-betta-two-url-merges/subversion: libsvn_client tests/cmdline
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 6, 2007 11:27 PM, C. Michael Pilato <cm...@collab.net> wrote:
> David Glasser wrote:
> >>>> 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?
>
> [...]
>
> > I might be suggesting that this logic belongs in do_merge somehow
> > instead of in the wrappers...
> >
> > Maybe do_merge should take an argument that is your "C" here?
>
> Perhaps, but it's not a change I'm motivated to make. As is, the public
> APIs are pretty thin wrappers -- merge3() might look like many lines of
> code, but most of them are just structure-stuffing, and near-duplicate
> multiples even of that.
Right, I think I'm suggesting that we might be able to put some of
that duplication into do_merge.
But it might not be that important.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r28303 - in branches/mo-betta-two-url-merges/subversion:
libsvn_client tests/cmdline
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
>>>> 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?
[...]
> I might be suggesting that this logic belongs in do_merge somehow
> instead of in the wrappers...
>
> Maybe do_merge should take an argument that is your "C" here?
Perhaps, but it's not a change I'm motivated to make. As is, the public
APIs are pretty thin wrappers -- merge3() might look like many lines of
code, but most of them are just structure-stuffing, and near-duplicate
multiples even of that.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r28303 - in branches/mo-betta-two-url-merges/subversion: libsvn_client tests/cmdline
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 6, 2007 9:02 PM, C. Michael Pilato <cm...@collab.net> wrote:
> David Glasser wrote:
> > On Dec 6, 2007 10:26 AM, <cm...@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...
I might be suggesting that this logic belongs in do_merge somehow
instead of in the wrappers...
Maybe do_merge should take an argument that is your "C" here?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r28303 - in branches/mo-betta-two-url-merges/subversion:
libsvn_client tests/cmdline
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Dec 6, 2007 10:26 AM, <cm...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand