Daniel Rall wrote:
>> 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.
>
Yes, Eclipse merge editor is OK in this regard and getting better.
>> 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. 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 22 02:24:58 2006