[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: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-10 20:00:14 CET

On Dec 6, 2007 11:27 PM, C. Michael Pilato <cmpilato@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_at_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
Received on Mon Dec 10 20:00:27 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.