You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2013/03/21 06:16:15 UTC
New merge APIs review, and JavaHL
Morning!
This is pretty much the last open issue I have with the JavaHL upgrade
to our new APIs.
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
svn_client_merge_reintegrate should be deprecated.
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.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: New merge APIs review, and JavaHL
Posted by Julian Foad <ju...@btopenworld.com>.
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