AW: Heuristics for merges

Hi, Julian,

Von: Julian Foad [mailto:julianfoad_at_btopenworld.com]
>
> Markus Schaber wrote:
> > I’m given a working copy and a merge from URL.
> >
> > Is there any easy heuristics I can implement using the SVN
> > 1.7 APIs to guide my user whether a sync-merge or a reintegrate merge
> > is appropriate? I want to display a warning message when the merge
> > will most likely fail.
> >
> > I know that SVN 1.8 does similar calculations internally to implement
> > “symmetric merge”, but I’m just looking for a simple, fast heuristic
> > using the public APIs, covering the basic use cases (we don’t allow
> > subtree merges or switches of subtrees, for example).
>
> I think you should be able to get a pretty reliable answer, given your
> restrictions, in most cases. You need to determine whether the most
> recent merge between these two branches was in the same direction or the
> opposite direction compared with the requested merge. Same direction =>
> you need non-reintegrate. Opposite => you need reintegrate.
>
> Pseudocode for a simplified method:
>
> source_mi = get_repos_mergeinfo(source-branch-root-path)
> relevant_source_mi = hash_get(source_mi, target_path)
>
> target_mi = get_wc_mergeinfo(target-branch-root-path)
> relevant_target_mi = hash_get(target_mi, source_path)
>
> if relevant_source_mi && relevant_target_mi:
> if latest_rev_in(relevant_source_mi) >
> latest_rev_in(relevant_target_mi):
> # you probably need a reintegrate merge
> else:
> # you probably need a non-reintegrate merge
>
> else if relevant_source_mi:
> # you probably need a reintegrate merge
>
> else if relevant_target_mi:
> # you probably need a non-reintegrate merge
>
> else:
> # maybe no merge has been done before, in which case
> # either is OK; or maybe one or both branches have been
> # renamed.
>
> I haven't fully checked what APIs are available for this, but I see there
> is svn_client_mergeinfo_get_merged() which might be all you need.
>
> Why do I say, "in most cases," "simplified," and "you probably need"? If
> the branch has been renamed, then simply filtering on the path of the
> other branch to find the "relevant" mergeinfo is not correct. (That's the
> "hash_get" step.) If you want this to work even when a branch has been
> renamed, then we need to dig deeper; let me know if you want help with
> that.

Thanks for your answer, I'll try to investigate this tomorrow. Let's see what parts of the API are exposed through SharpSVN, and what other parts I need to add there.

For now, "in most cases" is probably enough, and as a long-term solution, we'll upgrade to SVN 1.8 eventually. :-)

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915