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 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.
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? What
if the user wants something like "mine before theirs"? In other words,
both?
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 21 21:52:24 2006