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.
Perforce and ClearCase both offer very well-liked GUI merge tools.
Perforce's works like Tortoise or Araxis (its internal behavior is
likely similar to what I describe for Subversion below), but IIUC
ClearCase is even smarter, taking file ancestry into consideration
while performing merges.
> But to give you an example, I tested this feature today. Until recent
> versions, merge always crashed.
That is certainly not promising. ;-)
> 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.
> Personally, I like doing it the Subversion way. Let Subversion do
> its stuff, then I can look at my working copy and see what it did,
> as well as resolve any conflicts. With the merge tracking stuff you
> are doing, it should just get even easier.
As far as automatically choosing which revisions to merge into which
files, Subversion's Merge Tracking will be an enormous productivity
gain. However, we're currently grappling with what this means for
conflict resolution...
When considering the merge history for the target of a merge (which
may have had revisions from the requested merge already cherry-picked
into it), the act of merging may become non-trivial, as the requested
range of revisions to merge may need to be broken up into several
ranges. Consider:
(cherry picked) don't merge
r0 <===============[=========(=============)=========]=====> rHEAD
[requested merge] merge merge
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!
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.
As it stands with the command-line 'svn' client, we're going to have
to short-circuit merging of subsequent revision ranges into a file
which previous experienced a merge conflict, and record that not all
revision ranges were applied. "Conflict resolution mode" will equate
to manual resolution (as you described liking with today's merge
implementation), and re-running the same merge command (which will
ignore revisions which have been applied, and only attempt to apply
revisions which haven't yet been merged into the file). 20 GOTO 10.
Thoughts?
- Dan
- application/pgp-signature attachment: stored
Received on Wed Jul 19 02:59:40 2006