Re: New merge APIs review, and JavaHL

Branko Čibej wrote:

> There are two revised merge APIs:
>
>     svn_client_merge5
>     svn_client_merge_peg5
>
> and also a whole new group of svn_client_automatic_merge_ APIs, and the
> (not revised) svn_client_merge_reintegrate. I'm in a dilemma as to which
> of these APIs to use in JavaHL; and I'm also wondering if
> svn_client_merge(_peg)5 should even exist, given the new automatic
> variants are supposed do supersede them, and whether

The automatic merge API *only* performs merge-tracking merges that are 'complete' (that take all source revisions up to rX).  If you want to do a non-tracking merge, or a merge-tracking cherry-pick merge, then _merge(_peg) is what you need.

> svn_client_merge_reintegrate should be deprecated.

I would suggest yes.  In general, I would suggest the Java API should track the C API unless there is a good reason not to.

Put another way, if we think the C API for merging is confusing / bloated / whatever, then we should address it there -- in the C API -- and then track the changes in the bindings.

For example, it might perhaps be reasonable to remove the merge-tracking support in the new revision of svn_client_merge5(), becaue that function is for performing a 2-URL merge and the automatic merge should replace the only really useful use case for that (which is the reintegrate use case).

> Regarding the latter, I'm given to understand that we will still have to
> use svn_client_merge_reintegrate in some -- extreme? -- cases, but IMO,
> it would be more correct to deprecate now even if the automatic merge
> doesn't cover all edge cases yet.

I agree with that principle, whether we consider the all-revs-are-merged-except-for-some-no-ops case to be extreme or not.

- Julian
Received on 2013-03-21 13:50:33 CET