Hi, Julian, Von: Julian Foad [mailto:julianf...@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.scha...@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
