[merge tracking] Handling notifications resulting from a merge

On Fri, 07 Jul 2006, Kamesh Jayachandran wrote:

> Garrett Rooney wrote:
> >
> >Uhh, maybe it's just me, but this seems like you're working around the
> >actual problem here.

Kamesh and I spent some time looking into this test failure today, and
this did indeed turn out to be the case.

...
> Even though the given merge leads to 'Skip' svn:mergeinfo is recorded.
> This causes subsequent force merge to fail.
>
> * subversion/tests/cmdline/merge_tests.py
> (delete_file_and_dir):
> 'svn revert -R B2_path' to make subsequent forced merges to succeed.
...

This turned out to be part of the broader scoped notification handling
changes necessary on the merge-tracking branch. My working plan for
handling these issues is written up in TODO [1]. I'd love to get some
feedback on the approach:

  * Handle multiple notifications for single WC items. Possible
    solutions include:

    * Output multiple notifications, but print divider lines
      indicating the revisions range to which a set of notifications
      applies. Introduce a new type of "skipped" notification for WC
      items which are already in conflict.

    * Collate changes as merge ranges are applied. Detect and handle
      collisions (multiple notifications to the same WC item), giving
      preference to later notifications (?).

  * Handle skips. Merge test 3 fails because a merge of a revision
    range which contains a delete will not delete locally modified
    files (at least, not without --force), but is still recording
    merge info.

    * If all changes in a merge are skipped, no merge info should be
      recorded for the target.

    * If only some changes are skipped, merge info should be recorded
      for the target, and recorded as empty (or with no modifications,
      if there is pre-existing merge info) for the skipped items.

  * Handle conflicts.

    * If a conflict is encountered, invoke a conflict resolution
      callback to give a Subversion client a chance to intervene. If
      resolution is successful, convert the notification from a 'C' to
      something else (e.g. 'M'). (Phase 2?)

    * Otherwise, stop applying merge ranges as soon as a second
      conflict is encountered in a WC item (as it might generate
      overlapping conflict makers, or apply a merge inside a conflict
      marker!), being sure to record partial application of merge
      ranges.

[1] http://svn.collab.net/repos/svn/branches/merge-tracking/TODO