Tools For Merging Diffs?

RossyB asks: "Are there any tools to assist merging 2/3-way diffs? When I work on large changes to CVS sources I copy the tree and edit it separately, but then if the CVS source is heavily changed I need to manually update my changes. Merge conflicts from CVS suck, dirdiff helps a bit, gtkcvs is okay, but what I want is a tool to show me the differences between two or three trees, and allow me to edit/copy/delete files to merge the two. Hooking into XEmacs so I had syntax- and change- highlighted source code (in two windows) would be fantastic."

Comments

How I do it

[RGRistroph]

I have worked quite a bit on a massive project which is kept in CVS. Other contractors occasionally change things in the code I am responsible for, usually when they changed a common data type, or fixed a small bug. I also have a separate in-house repository for our code, which usually has much more changes, and perhaps a few branches with different experiments, some which worked and some which didn't. At some point we call for a code freeze for a delivery, and this is how I do it:

I check out two code trees to be merged, and I run ediff-directories in XEmacs over both of them, from the top level. I sit there and spend three or more hours going through every diff by hand, looking at every single one. If I am conscientious about keeping up to date and do this once every two weeks or so, then it will take half an hour, because I will know all the places where nothing has changed. You can look a the file sizes and quickly filter through files which are the same.

You have to be careful about new files in one tree that aren't in the other. ediff-directories is not good at making that obvious; I think the 'D' key will show you all files in one directory and not in the other.

Then I use pcl-cvs as my cvs interface and commit everything. There is a key shortcut to do a diff of the current modified file and one in the repository ( the '=' key, I think); you can make this do ediff if you wish. I look again at every single change that is going in.

There is a three-way ediff, and I've used it, but I personally find it preferable to merge one tree at a time into a base tree.

The ediff-directories tool and pcl-cvs are invaluable. I could live without pcl-cvs but not without ediff. So I think, if your problem is really that you lacking tools, then M-x ediff-directories is your saviour.

Now, if we really used CVS the way we should (too often it is simply used as a backup and distribution device) then those code trees would all be branches in the same repository. It's a bit easier then, because you can use CVS to merge the branches. (Look at the CVS manual by Per Cederqvist for details.) If two branches have a lot of conflicts, you might be better off with checking out separate copies and ediff, but that would be unusual.

If with ediff and CVS at your disposal you still find yourself overwhelmed with merging, then it is time to re-examine your development process. You may have to force two developers or development groups to start using the same branch. If their stuff has to be in the same tree at the end, the best way to merge is to merge them as you write. Just because you have CVS, doesn't mean that you are under configuration management; you have to actually use it as you develope.

I would not be at all surprised if your problem is not that you lack tools, but that your groups' method of development is not collaborative enough. Developers like to grab a copy of the code and go off and work for weeks and come back and plop it in your lap. If they are really mule-headed about it, demand that they commit all changes at the end of every day, delete their working copy, and check out a new copy the next day.

But hopefully ediff-directories is your answer.

TkCVS Integrates TkDiff -- can you say GUI

[brsett]

TkDiff is a very good diff tool. Almost identical to cleardiff if you've ever used clearcase. It is integrated with tkcvs, which I also strongly endorse (although I use the command line for some of the hairier stuff). Search on TkCVS and TkDiff. Terminal diff (along with just about every other visual terminal tool) sucks.

emerge

[Russ Nelson]

You're looking for emerge.

Re:emerge

[Alan Shutko]

Actually, you want ediff-merge. emerge is a separate, older package and (imho) isn't as good.

(At least, on Emacs. I don't know if xemacs nuked emerge and replaced it with ediff.)

whitespace issues are the worst

[mrob]

In my experience, the biggest problem with merging diffs happens when two or more developers have substantially different indentation formatting settings. For example, one developer using K&R style and another using the GNU style. Sometimes (particularly if the tab settings are different) I have to reindent the whole file before I can even read the code (C programmers understand why).

The reason this is a problem with CVS is because CVS does not make it easy to make reindenting an automatic part of the checkin/merge process. If CVS could reindent each file before diffing it against the repository, there would be a whole lot fewer diffs to actually merge. As it is, reindenting essentially kills CVS's ability to merge a branch back into the trunk.

- Robert Munafo