Merge conflict resolution

Hello Subversion IDE developers. I'm currently working on building
Merge Tracking support for Subversion. As part of this journey, I've
discovered that writing merge conflict markers into a file isn't
conducive to a friendly user experience when applying multiple
revision ranges during a single merge operation (or otherwise, for
that matter :). I need to allow for a better way of handling merge
conflict resolution in Subversion, and I'd like your help in assuring
that this is designed from the ground up with Subversion IDEs in mind.

Background:

While conflict markers might not currently seem like much of a problem
to most people (at least, to those not grumbling that Subversion is
"corrupting their files"), Merge Tracking really complicates things.
In today's Subversion, we apply only one revision range during any
merge operation. With Merge Tracking, we may apply multiple revision
ranges during a single merge operation, a rather fundamental
difference with many ramifications. Once a file has a merge conflict,
we have to stop applying revision ranges, meaning that we might apply
only a portion of the revisions requested for merge by the user.
Improved merge conflict resolution handling will really help address
this user experience.

Requirements:

- Allow merge conflicts to be resolved during application of a merge.

- Allow as much automatic merging to be performed as possible without
requiring human interaction.

- Allow declarative conflict resolution to avoid any human interaction
(e.g. --resolve-conflict-using=[older|theirs|mine]), supporting some
degree of conflict resolution from merges (e.g. build automation).

- Maintain compatibility with the diff3 command.

- Allow for resolution more types of conflicts (e.g properties,
obstructions, etc.).

Possible implementation:

Subversion will first attempt a merge via its built-in diff library,
or the diff3 command specified in its config file (or via the
--diff3-cmd option, for the command-line client). If a merge conflict
occurs to either content (file or directory) or properties, it will
invoke a merge conflict resolution callback provided via its
svn_client_ctx_t structure (we may provide a default implementation of
this which calls out to an external binary a la the diff3 command used
in the original merge). This callback would prompt the user to
resolve the conflict (when in non-interactive mode), and upon
resolution allow subsequent merge of revision ranges to occur into the
same file (important for Subversion's Merge Tracking support). For
the command-line client, the callback would throw up a prompt
something like:

  Merge conflict detected for "foo.c" at line 37
  mine:
   struct iovec vec;
  theirs:
   int k;
  older:
   int i;
  Retain (m)ine, (t)hiers, or (o)lder version? _

IDEs could obviously do something even more user-friendly, throwing up
a three-way merge GUI like TortoiseMerge, WinMerge, Araxis Merge,
etc., but ONLY when a merge conflict actually occurs.

If the callback notes that the conflict was resolved, its WC state
will be automatically changed accordingly.

Question for IDE developers:

I'm really curious how IDEs handle this situation today. Taking
TortoiseSVN as an example, I've heard that its TortoiseMerge diff3
program is great for conflict resolution (though currently lacking an
edit mode), but not so great for performing merges of a large number
of changes (e.g. merging changes from trunk into a feature branch),
especially when the majority of those changes can be applied
automaticaly with no merge conflicts (and thus don't need typically
need a merge GUI). Is this an issue for TortoiseSVN/TortoiseMerge
today, or am I out of date? How about for other IDE developers? How
do you guys handle this today? ;-)