On Wed, Mar 27, 2013 at 12:18 PM, Julian Foad
<julianf...@btopenworld.com> wrote:
> Brane told me that while updating the JavaHL API he noticed that the new 
> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make 
> the existing JavaHL merge API encompass that functionality rather than add 
> yet another variant.  So I said if let's see if we can apply that idea to the 
> libsvn_client API.
>
>
> Idea: 'automatic' merge is (in a high level logical sense) most similar to a 
> subset of the 'pegged' merge.  So make 'merge_peg' do the automatic merge 
> (like calling the automatic merge API) if the params are suitable.  The 
> intention is that this should be easier for Subversion client developers to 
> understand and for them to DTRT.
>
> API differences between pegged and automatic merge:
>
>                 Pegged merge                       Automatic merge
>
> The 'find'API: Single merge_peg call does        Separate'find' and 'do' 
> calls.
>                 the whole process.                 Result of 'find' tells 
> what we found,
>                                                    used for 'svn mergeinfo' 
> graph.
>
> Source:         revision ranges X:Y[,X:Y...]       revision range 0:Y
>                 on branch URL@PEG                  on branch URL@PEG
>
> Target:                                           optional non-WC tgt for 
> 'find'
>
> If mergeinfo:   skip already-merged revs           (same)
>                 record the merge
>
> No mergeinfo:   don't skip revs                   error out
>                 don't record
>
> Options differ: allow_mixed_rev                   allow_mixed_rev
>                                                    allow_local_mods
>                                                    allow_switched_subtrees
>                ignore_mergeinfo
>
> At that level, it looks close enough to be feasible to embed 'automatic' 
> merge inside 'pegged'.  I'm looking closer now.
>
> Any thoughts?

There are obviously some benefits for having less API, especially when
it comes time to rev it for something.  That said, as a caller of the
API, it seems nice that the separate "automatic merge" API can provide
a more focused and simpler interface.  For example, the interface does
not need to expose things like a revision range, which should not
apply when doing this kind of merge, but obviously is needed when
doing a cherry-pick merge.

Looking through a long list of API is hard sometime, but it is also
hard when you want to do something like merge everything in BranchX
and the interface requires passing a bunch of parameters that do not
directly apply.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Reply via email to