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

In case my last post didnt help..

[chowda]

Here are some links... FROM FRESHMEAT... both claim to do multiple diffs... one claimed 3 files... the other just says multi... I can't help with your emacs dependency though... methodone works for heroine adicts though...

http://freespace.virgin.net/david.drysdale/xwindif f.html
http://xxdiff.sourceforge.net/

Re:In case my last post didnt help..

[Domini]

You can have a look at a windows product called 'WDiff' version 1.49 over HERE .

It's not free, but it's an option, It has quite cool simplistic but visual merging.

Hope this helps someone... it sure helped me in my last Linux/Delphi project (used CVS)

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.

Re:How I do it

[Bill Barth]

There's also an emerge option in Emacs with a whole list of options (emerge-merge-directories bein, perhaps, the most helpful here).

Re:How I do it

[jmalicki]

The real answer is not to use CVS. You should be checking in related changes as a unit when they work, not just in progress/won't compile/buggy as hell. CVS is really a horrible tool for large group development, espescially in its "Argh! I give up" handling of conflicts. A decent version control system can handle most merging on its own, and then give the user an easier way of dealing with the /real/ conflicts.

Re:How I do it

[ethereal]

I have to give props to ClearCASE here - it handles most merging on its own and has fairly nice graphical diff and merge tools. It makes it really simple to make branches for new development, so in our group every bug fix/new feature is coded, built, and tested on a development branch first before being integrated into the main build. Also, developers are required to merge the latest main line versions of the files back onto their bug fix branches before bringing them back to main line, so all the merging pain is done by the developer (who is most familiar with their changes anyway) and the builder's merge to main line is a simple copy. The only problems occur when you have multiple changes to the same files coming in to main line at the same time, but that would be a problem with any build process and really is a communication issue, not a technical problem.

Of course, ClearCASE is in some regards way more complicated than that, and probably overkill and too expensive for most open source projects. I've seen a nice CVS front-end called Cervisia which looks sort of like ClearCASE; I haven't used it but it might be sufficient.

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.

dirdiff

[Chris Siebenmann]

I have used dirdiff for this in the past. It has a good interface for dealing with two directory hierarchies, but I found its interface for the actual diffs to be a bit clunky (although it may have improved since I tried it). And it has a decent collection of features.

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.)

diff3

[The Pim]

I'm happy with the humble diff3. The reason is simple: it finds the conflicts, then gets out of the way and lets me use my editor for the real work. The familiarity of the navigation and editing commands, along with amenities like syntax highlighting, typically outweigh the advantages of a dedicated merge tool. Most non-trivial merges require understanding the changes in the context of the whole file, for which an editor is well suited.

The other tool I have significant experience with is the Rational ClearCase merge tool. This is fast for the simplest of conflicts, when the conflicting sections are short and you're already familiar with the deltas on the two branches. Anything harder, and it gets awkward.

Now, Rational's GUI's absolutely suck, so maybe something with a better interface could win me over, but it would have to be pretty slick to compare with vim.

Re:Please god.. help these poor mortals!!

[RossyB]

Tried freshmeat... nothing there does everything I want. I don't want to use two or three tools just to see the conflicts.

Re:Please god.. help these poor mortals!!

[chowda]

try this other thread for what you can find at freshmeat....

Yes, exactly

[FascDot Killed My Pr]

I've only used this a couple of times, but both times it was an absolute GODSEND. Available from emacs, it windows itself, shows both source files and what the final will look like. Easy to use.
--
Give us our karma back! Punish Karma Whores through meta-mod!

Visual SlickEdit

[vutpakdi]

VSE has a really nifty diff/merge utility (Diffzilla). It's saved my butt at the last two companies. You can point it at two different directories, and it'll show you all of the different files in both directories. You can then merge changes back and forth either visually or automatically. Editing in the diff windows is also supported. VSE is a terrific editor and is available on multiple platforms. www.slickedit.com is their website.

Re:ClearCase

[staplin]

I'll agree that ClearCase can do very well on simple merges, and their GUI didn't bother me that much (once I got used to it), but you're right that it's very, very easy to confuse their merge algorithm.

For example, 2 users add an identical line of code, but if one user adds it above line 12, and another adds it below line 12, ClearCase will happily add both of them, without even warning you. Now this may not count as a "real" conflict, but you'd think it would be easy to identify.

I've also seen it get really confused if methods are very similar, trying to merge them when what is really needed is the addition of both.

Despite these shortfalls, it does happen to be one of the best merge tools I've worked with.

Now if only there was something like it that worked with a simple versioning system like CVS instead of that monstrous beast that ClearCase uses...

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

Re:whitespace issues are the worst

[stevey]

If you're working in a team then coding standards would really help you out here.

Even if it was something adhoc; like asking people to run Indent on source before commiting it.

Or, if you're generating diffs by hand you could ask people to use "--ignore-all-space", and "--ignore-space-changes" which forces diff to ignore changes in whitespace.

Steve
---