[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Heuristics for merges

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 30 Aug 2012 17:02:26 +0100 (BST)

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
      # 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

    # 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
Received on 2012-08-30 18:03:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.