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
