On 27.03.2013 17:18, Julian Foad 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?
This is pretty much the same conclusion I came to earlier today. I looks
like the easiest thing to do would be to make the _automatic_ APIs
private within libsvn_client, move the selection logic to
svn_client_merge_pegX, and simplify the client implementation.
The only trouble with that is, as you say, that "svn mergeinfo" relies
on having the automatic_find API available. I think this could be solved
in several ways:
1. by splitting the merge-peg into two, as the current automatic-merge; or,
2. by making only the "do" phase of the automatic merge private, and
wile leaving the "find" phase public -- but renaming it to something
more in line with merginfo discovery; or,
3. somehow exposing the "find" phase through one of the existing (or
revised) svn_client_mergeinfo_* APIs.
I'm kind of leaning towards #3, but don't have a sense of how
complicated that would be.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
