Re: Merge conflict resolution

Thanks for the response, Mark! Comments inline below.

On Tue, 21 Nov 2006, Mark Phippard wrote:

> Daniel Rall wrote:
> >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.
>
> I assume what you are saying is that the callback would occur on the
> conflict, not at the end of the process.

I'm envisioning the conflict resolution callback being invoked after
merging of an individual revision range (e.g. "-r 3:7") occurs into a
single file, but before merging of any changes from that revision
range to any other files affected by application of the patch.

> I do not see how a GUI tool could handle this well, without being
> really custom written for the purpose. The GUI editors you mention
> all want to deal with entire files, not sections. I almost think a
> GUI would have to be custom and be somewhat like what you provide
> for the command line. Perhaps being a GUI, it could show some more
> file context. Hard to say. In Subclipse we are using the 3-way
> merge editor provided by Eclipse, I do not know if it has any way to
> be driven like this.

I'm assuming that GUI merge tools would deal with conflicts on a
file-by-file basis. The section-by-section example I showed above
would be a custom implementation of this conflict resolution callback
specific to the command-line client, which would take a file in
conflict and ask you to resolve a section at a time via the prompts I
described above.

I'm betting the 3-way merge editor provided by Eclipse will handle
this file-by-file merge just fine.

> What responsiblity will the callback function have? Will it just be to
> return a code of some sort that tells you which revision to take?

I'm assuming that the callback will take care of doing the actual
merge, and that Subversion libraries will handle the WC meta data
manipulation. Here's the API I've integrated in the tree delta editor
(from libsvn_client/repos_diff.c); I may actually want to push this
deeper, down into the WC's editor:

/** A callback used for resolving merge conflicts to content or
 * properties encountered during the application of a tree delta to a
 * working copy.
 *
 * This callback is only invoked when not in "dry run" mode. It
 * provides for a smooth balance of automated merging via a
 * non-interactive diff3 mechanism like Subversion's internal
 * implementation (or an external tool like GNU diff specified via @c
 * SVN_CONFIG_OPTION_DIFF3_CMD), and declarative or interactive merge
 * conflict resolution (e.g via an external tool like TortoiseMerge or
 * Araxis Merge).
 *
 * If @a content_state and/or @a prop_state are not @c NULL, and the
 * conflict is resolved during the callback, set @a content_state
 * and/or @a prop_state appropriately (e.g. likely to @c
 * svn_wc_notify_state_merged); housekeeping for the resolution of @a
 * path will occur automatically. If @a content_state and/or @a
 * prop_state are not @c NULL but returned unchanged, it's assumed
 * that the conflict has not been resolved.
 *
 * All allocations should be performed in @a pool.
 *
 * @a baton is a closure object; it should be provided by the implementation,
 * and passed by the caller.
 *
 * @since New in 1.5.
 */
typedef svn_error_t *(*svn_client_conflict_resolver_func_t)
  (const char *path,
   svn_wc_notify_state_t *content_state,
   svn_wc_notify_state_t *prop_state,
   svn_boolean_t dry_run,
   void *baton,
   apr_pool_t *pool);

> What if the user wants something like "mine before theirs"? In
> other words, both?

With a 3-way merge tool like the one provided by Eclipse, I'm assuming
mixing changes on a line-by-ine basis (and probably even editing in
place) is no problem.

With the command-line client, you'd do something like you'd do today
(and open up the file in your editor).

> >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? ;-)
>
> In Subclipse when you choose to Edit Conflicts we take the 3 files
> and feed them to the Eclipse merge editor. There is a button to
> merge all non-conflicting changes, but the user has to use it or
> walk through every change, not just the conflicts. I often just
> open the marked up file in an editor and fix it myself.

Ah! This sounds similar to the situation I'm guessing arises with
TortoiseMerge (as described above). Does this mean that Subclipse
could also benefit from a merge conflict resolution callback, allowing
Subversion to handle the obvious merging, and opening up the Eclipse
3-way merge tool for only the conflicts? Or do I misunderstand?

- Dan