Re: Fold the merge_automatic API into the existing merge_peg API

Julian Foad wrote on 2013-04-01:
> TODO: Decide whether to keep or make private or delete the dedicated
> 'automatic merge' APIs.

The issues are:

  * Do we want the API to be a special case of pegged merge, or a
    dedicated API?  (I don't want to clutter the API by having both
    forms.)  Using the pegged merge API makes a lot of sense, so
    that seems to be the winner.

  * What API should we use to access the 'svn mergeinfo' information?
    The best option would seem to be a dedicated API, something like
    the current 'find_automatic_merge' but less fussy.

PROPOSAL

  * Make the 'automatic merge' APIs private, leaving svn_merge_peg5(
    rev-range=null) as the public entry point.

  * Deprecate svn_client_merge_reintegrate().

  * For getting a mergeinfo graph, combine the 'find_automatic_merge'
    API with the two getters (svn_client_automatic_merge_is_reintegrate_like(),
    svn_client_automatic_merge_get_locations()) and return that
    information directly.  Rename to 'get merge history summary' or
    something like that.

DISCUSSION

The 'automatic merge' performs a merge of 'all changes up to rX' from
the given source branch to the given target branch.  There are currently
two ways of representing this in the libsvn_client API:

  * Use the 'pegged merge' API with a null revision range.

  * Use the dedicated 'automatic merge' APIs.

Differences:

    - The 'automatic merge' API is split into 'find' and 'do' parts.
      The rationale was so the caller can provide better feedback on
      what's happening and potentially ask the user to confirm, for
      better user awareness, to try to minimize user error.  That isn't
      essential, and that isn't the only way of providing feedback, and
      the same could be done to the pegged merge API if we wanted, so
      this should be neither pro nor con.

    - With svn_client_merge_peg5(), passing 'ignore_mergeinfo' returns
      an error.  With the dedicated API there's no such option, as use
      of mergeinfo is necessary.

    - The flags for allowing the target WC to have mixed revs, switched
      subtrees etc. are a bit different, but not in important ways --
      the automatic merge API has more flags than necessary.

Review of merge APIs new or changed in 1.8:

  svn_client_find_automatic_merge()
  svn_client_find_automatic_merge_no_wc()
  svn_client_do_automatic_merge()
  svn_client_automatic_merge_is_reintegrate_like()
  svn_client_automatic_merge_get_locations()

    - See the proposal above.

  svn_client_merge5()

    - The two meanings of the old 'ignore ancestry' are now controlled by separate 'ignore_mergeinfo' and 'diff_ignore_ancestry' flags.  I think this is fine.

  svn_client_merge_peg5()

    - The two meanings of the old 'ignore ancestry' are now separated.  'automatic merge' behaviour is now available, by passing in a null revision range.  I think this is fine.

  svn_client_mergeinfo_log2()

    - This has just grown a revision range input.  I think this is fine except the interpretation of 'unspecified' revisions could be cleaner.

I'll make this happen as proposed above, ASAP, unless I receive other suggestions in the meantime.

- Julian
Received on 2013-04-10 15:15:18 CEST