[Gnu-arch-users] some lkml discussion of a graphical merge tool

[Zack Brown]

Hi folks,

The following are snippets of lkml email dating back to 2001, talking about
merge tool requirements. I hope they're useful.

Be well,
Zack

                                    * * *

On 20 Jun 2001, Larry McVoy said:
> the entire BK GUI is in tcl/tk, almost 20,000 lines of code (that would be
> 80,000 for you Java fans), and the GUI has revision history browsers,
> changeset browsers, source browsers, check in tools, diff tools, rename
> tools, file mergers, etc. It's pretty complete and it typically comes very
> close to just working across all platforms. The sort of differences we
> deal with are little things like the font names not being the same on
> Unix/NT.

                                    * * *

On 3 Nov 2001, Larry McVoy said:
> as you move through the diffs, the checkin comments for the affected lines
> will show up in the top two windows (very handy when you are scratching
> your head and wondering why did someone change this).
> 
> It takes a little getting used to and it could sure use some docs, but we
> have compared this to other graphical merge tools out there and think we
> have the best of the lot. It takes advantage of some unique information we
> can extract from the data in the revision control system; unless you have
> a very similar revision engine, it's impossible to do as well as we do.
> And for you poor PPC BK guys, yeah, we know that the original merge tool
> sucked. You'll like this better.
> 
> Anyway, getting back to Linus & Co, and for that matter, open source
> efforts in general, they typically have a somewhat different model than
> BK. In BK today, before you can push up a change you have to merge it with
> whatever is in the tree to which you are sending the change. In other
> words, each user merges rather than the maintainer. We're well aware that
> not everyone likes this model so we're working on a small set of changes
> so that users can push their changes to the maintainer and the maintainer
> merges them. This makes merge tools even more important to the maintainers

                                    * * *

On 27 Dec 2001, Larry McVoy said:
> in the interesting case (i.e.,
> it won't patch cleanly), both text based and GUI based tools are available
> to help with the merge.  They are better than anything you're used to or
> I'll eat my hat.  For example, if you are a CVS user, you are used to this:
> 
>     <<<<<<< local slib.c 1.645
>                   sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
>                   assert(HASGRAPH(sc));
>                   sccs_sdelta(sc, sccs_ino(sc), file);
>     <<<<<<< remote slib.c 1.642.2.1
>                   sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
>                   assert(sc->tree);
>                   sccs_sdelta(sc, sc->tree, file);
>     >>>>>>>
> 
> but we can give you this:
> 
>     <<<<<<< local slib.c 1.642.1.6 vs 1.645
>                   sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
>     -             assert(sc->tree);
>     -             sccs_sdelta(sc, sc->tree, file);
>     +             assert(HASGRAPH(sc));
>     +             sccs_sdelta(sc, sccs_ino(sc), file);
>     <<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1
>     -             sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
>     +             sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
>                   assert(sc->tree);
>                   sccs_sdelta(sc, sc->tree, file);
>     >>>>>>>
> 
> Why is that better?  It's essentially two inline context diffs, so you can
> see what each side did.  Much easier to merge when you can tell what is
> going on.
> 
> The GUI tools give you the second style as well as some extra windows
> so you can see the checkin comments associated with both the deleted and
> the added lines, which gives you yet more information.

                                    * * *

On 7 Feb 2002, Tom Lord said:
> Aside from the fancy merge operators built-in to arch, arch's second layer
> makes the choice of merging technologies largely orthogonal to the
> revision control system.

                                    * * *

On 07 Mar 2002, Andrew Morton said:
> The problem I find is that I often want to take (file1+patch) -> file2,
> when I don't have file1. But merge tools want to take (file1|file2) ->
> file3. I haven't seen a graphical tool which helps you to wiggle a patch
> into a file.

                                    * * *

On 07 Mar 2002, Rik van Riel said:
> Merging patches up to a new version of the kernel has gone from
> tiring (with patch and vi) to almost relaxing (with bitkeeper's
> automatic and graphical 2-way merge tools)...
> 
> This in turn has allowed me to spend my time and energy on
> improving the code, without having to fear large patches and
> the maintenance those require.

                                    * * *

On 8 Mar 2002, Neil Brown said:
> I would like a tool
...
>                     that would show me exactly why a patch fails, and
> allow me to edit bits until it fits, and then apply it.

                                    * * *

On 17 Mar 2002, David Woodhouse said:
> Another thing I have a distinct feeling I'm going to want is tracking
> functions across files. I sometimes shuffle functions between files for
> portability - selective compilation is nicer with your Linux-specific
> functions in one file and eCos-specific functions in another than with a
> litter of ifdefs. If Linus' tree gets a patch to a file that I moved, BK
> can work it out. If Linus' tree gets a patch to a _function_ that I moved
> to a different file while leaving the rest of the original file in place,
> AFAICT not even the merge tool deals with that nicely. Did I miss an
> option to 'apply this diff hunk to a different file'?

                                    * * *

On 16 Mar 2002, Jeff Garzik said:
> On 16 Mar 2002, Larry McVoy said:
> > The problems show up when the same patch is applied N times and
> > then comes together.  The inodes collide.  Right now, you think that's
> > the problem, and want BK to fix it.  We can fix that.  But that's not
> > the real problem.  The real problem is N sets of diffs being applied
> > and then merged.  The revision history ends up with the data inserted N
> > times.
> > 
> > I'm not sure what to do about it.  I can handle the duplicate inode case
> > more gracefully but it's a heavy duty rewack.
> >
> 
> Hence my suggestion for a short term solution that's immediately useful
> -- allowing some way to answer "local changes take precedence 100% of
> the time" or "remote changes ..." with a single command.  That was my
> hack solution that I thought would people might find useful when stuck
> with the duplicate-patch situation.
> 
> In the command line merge tool, when merging a file-create, "rla" would
> cause the current file conflict, and all future file-create conflicts,
> to be "won" by the remote side -- essentially creating the effect of
> typing "rl" 300 times.
> Apply similar logic to the file-rename merge case.  I think the merge
> command I used in 100% of the cases, during that merge, was 'r'.
> 
> If you are stuck with the duplicate patch case, as happened here, I just
> want to see the pain eased a bit :)  IMO you can put off the hard
> problem if you make the UI a bit better.

-- 
Zack Brown