On Tue, 21 Nov 2006, Mark Phippard wrote:
...
> >>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?
>
> I don't know. If in the end we still just feed the merge tool the
> same 3 revisions, it is going to give the same results.
Yes. The benefit that I am hoping to achieve is to avoid spawning a
GUI merge tool for files which can be merged automatically via
Subversion's built-in diff3 library, but spawn a GUI merge tool
*during the merge* as-needed for files which require manual
intervention to merge.
Does Subclipse already work in a similar fashion? Perhaps the merge
is automated, but you come back and manually resolve the conflicts
using the GUI merge tool?
> I guess the improvement would be if there was a 4th revision where
> the stuff that could be merged was, and the conflicts still looked
> like the base revision. Then the merge tool would likely only have
> the conflicts. We cannot do this today because the marked up
> revision would not work in the merge tool.
Right. While this was not part of what I was originally proposing,
it's certainly an interesting idea. I think we should file this as an
enhancment.
- application/pgp-signature attachment: stored
Received on Tue Nov 28 20:21:24 2006