Daniel Rall <dlr@collab.net> wrote on 07/18/2006 08:59:15 PM:
> On Tue, 18 Jul 2006, Mark Phippard wrote:
>
> > Daniel Rall <dlr@collab.net> wrote on 07/18/2006 06:48:32 PM:
> >
> > > While I have not used Subversive, from a marketing perspective the
> > > most compelling of their advertised features is "Interactive merge
> > > operation, similar to merge in Eclipse CVS plug-in".
> >
> > Given all of the work you have been doing on merge in Subversion, I
> > am surprised you feel that way. I think this "feature" is the
> > biggest crock in all of their stuff I have seen. Personally, I do
> > not think it is possible to do this. I do not think the API's are
> > really there in Eclipse or SVN. Although, I do admit that I do not
> > know why CVS would be different.
>
> I'm assuming that all this is is an interactive GUI for a basic two-
> or three-way merge, which involves merging the differences from
> revision "A" to revision "B" into "our" revision. In the usual case,
> "our" revision -- with or without local mods -- is often used for "B".
>
> With Subversion today, you can use third-party merge tools like
> TortoiseMerge <http://tortoisesvn.tigris.org/TortoiseMerge.html> or
> Araxis Merge <http://www.araxis.com/> to present a GUI to help with a
> two- or three-way merge. You select which lines you want, and are
> able to make manual edits as well.
Eclipse also includes built in functionality for 2 and 3-way merge. A
"Team Provider" simply has to provide the mechanisms for providing the
input content to the Eclipse engine. The limitation we have with this, is
that we would like to be able to supply the engine a Unified Diff file and
let it use that to build a GUI merge. Instead we have to provide it the 2
or 3 files and let it do it.
This screenshot gives a bit of an example:
http://subclipse.tigris.org/images/sync-ss.png
> > Anyway, last week I changed the license headers in all of the code.
> > Today I committed some other changes to files. I wanted to merge
> > just todays changes to our 1.0.x branch. Pretty classic merge
> > scenario. I entered all of the correct data in their merge dialog,
> > and the Synch view brought up just the files that I changed in the
> > revision I wanted. However, when I brought up the interactive
> > merge, it was just a straight compare of the 1.0.x version with the
> > trunk version. In other words, the license header changes also
> > showed up as differences to bring in. That is exactly what I
> > thought would happen, and in my opinion makes the feature useless.
>
> This sounds like a rather severe bug in the implementation of
> Subversive's merge tool.
The Eclipse engine is not very well suited for what would be needed, to do
this right, you'd probably have to provide your own classes for almost
every piece. I am also not sure what kind of "merge output" can be
extracted from Subversion. You can certainly simulate merge by producing
a diff, but it is not exactly the same. It is possible that JavaSVN is
doing something at the protocol level to extract the merge actions. Right
now, it appears to me that that all they are doing is something like merge
--dry-run to get a list of what files merge would update, and it then just
shows the files in a list and lets you use the Eclipse merge. Since it
works on whole files, it cannot produce the right results when you are
doing "cherry-picking".
> Say I run 'svn merge -r3:7', for a merge target which has already had
> r5 merged into. Internally, libsvn_client must do the equivalent of
> 'svn merge -r3:4' and 'svn merge -r5:7'. Sounds simple enough, until
> you get a conflict from application of the first revision range. If
> the second revision range also contains changes to the conflicted
> file, you cannot apply it for that file for several reasons: 1) the
> presence of existing conflict markers may confuse the "patch" logic
> 2) worse, conflict markers may overlap 3) even worse, merges could
> occur *inside* the conflict markers!
Yes, I have been following these discussions on the Subversion dev@ list.
> With the introduction of merge tracking, the value of interactive
> merge tools to parallel development increases significantly. If
> Subversion was able to offer a "conflict resolution" callback API to
> clients like Subclipse and Tortoise, their ability to resolve merge
> conflicts interactively could enable Subversion to continue merging
> into a file which had experienced a conflict from application of a
> previous revision range.
That sounds interesting. Take a simple conflict example like you would
get today. We are able to take the "mine", "left" and "right" files and
give you a 3-way merge editor to resolve the conflicts. If we had
something similar we could do it. If we had more then 3 files, or not
even a complete file, I am not sure. In the long term, with the right
amount of custom Eclipse code -- possibly.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Wed Jul 19 03:13:38 2006
