On Wed, Mar 27, 2013 at 12:18 PM, Julian Foad
> 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_at_PEG on branch URL_at_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
> 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
Received on 2013-03-27 17:53:35 CET