Re: Heuristics for merges

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).

Hi Markus.

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.

- Julian

--
Subversion Live 2012 - 2 Days: training, networking, demos & more! http://bit.ly/NgUaRi
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download