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_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
> 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
Received on 2013-03-27 17:45:16 CET