What makes MergeRight better than other Merge tools?

The attention to the human interface

While there are many tools available to support the comparison and merging of text and source code, MergeRight stands above the rest by its attention to the cognitive capabilities of the people who use it.   In the following document, we compare MergeRight to the key competitors and attempt to explain just what can make MergeRight users so much more productive than users of other tools.

The underlying comparison engine

While MergeRight's fundamental advantages are its human interface, its underlying comparison engine is also the best there is.  We use the file comparison algorithm developed by Webb Miller and Eugene Myers, now coded in Java.  This algorithm has been mathematically proven to produce the optimum (smallest) set of differences and in the fewest number of individual string comparisons.  While MergeRight is not alone in using this algorithm, many commonly used comparison programs such as the Unix diff program use different algorithms which are known to be considerably slower and can generate poor sets of differences.

A comparison to other tools: MergeRight vs. Merge Wrong

It's easy to look good when you choose who to compare against. But, we've tried to do better, and compare ourselves to some award winning products, such as Symantec's Visual Cafe, and Perforce, regarded by some as best of their breeds. Still, they don't just do merge tools, so perhaps it is not surprising that a lot of what makes them great is their other features. We think that users of these tools could improve their experiences by replacing the built-in merge tools with MergeRight. Luckily, these tools make that easy to do. But let's see how MergeRight is superior to these other built-in tools.

In the comparison figure below we see three views of tools used to merge files, MergeRight, the built-in difference tool in Symantec's Visual Cafe, and the results of the Perforce automated merge, inside a program editor. While there are many comparison and merge tools available, often integrated in various editors, development environments, version control and software configuration management systems, these are typical of the two main alternative approaches to merging, other than using MergeRight's unique concordance style interface.  Luckily for those who use integrated environments, MergeRight is especially designed to be easily integrated as a replacement or supplement to the tools in these programs and development environments.  Once integrated, MergeRight can be used automatically whenever you need to do a merge

Comparison vs. Merge

Tools for merging come in two flavors, those that merely compare two files, and those that can merge differences to create a new result file. MergeRight is a full merge tool, it not only shows you what the differences are in the two branch files you are comparing, but it allows you to "resolve" the differences and create a new result file with both sets of changes. At the same time, you can't inadvertently change the files being compared, because only the new result file is written, the branch files are left read only.

Comparison tools are typified by the Symantec Visual Cafe file compare tool, shown below. They don't have the ability to create a new result file with both sets of changes. While you can edit either of the two files that you are comparing (even accidentally) you can't create a new result file.

Perforce,a commonly used version control and software configuration management tool does create a merged result file, but it does so by writing comments into the code which must be searched for and edited out. Where changes don't conflict there are no markers making it difficult to see what changed, and impossible to detect semantic errors that can be introduced in "automatic merges".

Merge Right!

3-way comparison and color coding allows you to see recommendations, and thereby tell when differing sections are due to additions or deletions.  That way you don't accidentally reintroduce old bugs that were deleted earlier. MergeRight is a full fledged Merge tool, not merely a comparison tool. It has a powerful built-in editor that allows you to quickly find areas of difference or common areas, and to edit them directly before committing the result. Moreover, MergeRight allows you to resolve differences in any order you want, and edit them. Giving you a what you see is what you get view of the result file before you commit it. Also, note how MergeRight allows you to temporarily "hide" the common sections, allowing you to focus on just what changed. MergeRight uses a concordance style display, so difference areas are ALWAYS side by side, never scrolled out of view of each other.  The concordance view also allows us to make it possible to commit and undo resolutions of differences in any order and as often as you desire.

Merge Wrong?

Symantec Visual Cafe is one of the leading and most awarded Java development environments. Yet it's built in comparison tool, while typical of such environments, is limited in its effectiveness. The Symantec Visual Cafe file comparison tool is typical of many "visual" difference tools.   It is not a full fledged merge tool, but merely a comparison tool; it shows you what differs in each file, but does not help you to create a new file that has both sets of changes. Since it only does 2-way comparisons, this program can't tell when code is present in one side but not the other whether that is because one programmer added the code or the other deleted it. The difference tool has only a limited understanding of which sections are different and they can only be traversed in a forward direction one at a time. Common areas are not hidden, distracting attention from the changes and making the changes harder to identify.

Merge Wrong?

The Perforce version control package is one of the most highly regarded version control tools available and for good reason. But its textual merge is typical of (and in some cases superior to) the built-in merge tools in most such version control systems. Still, it has limitations in comparison to MergeRight. The Perforce merge command does create a merged file, but because it is not interactive, it isn't able to resolve conflicts. Instead, it writes comments (seen here with >>> === and <<< marks) directly into the code.   You then have to take the result file and post process it with an editor, searching for the makers (>>>, etc.) and removing them and correcting the file.  This is not only a strain on the cognitive abilities of the user,  which alone introduces errors, but even more subtle semantic merge errors can be introduced, and Perforce (and other automated merges) may instead indicate that there are no problems. Because such semantic problems compile, but generate results not in either file they are especially difficult to find and fix. Features Compared

Comparing files just means looking at how the files differ from each other or from a common ancestor. As such it is a completely nondestructive activity. Because MergeRight uses a "concordance" view mechanism, it is always easy to see what is the same in both files and what is different. From menu items inside the View menu you can hide all the common areas so you can focus on just the differences, or if you prefer, hide all the difference areas and show only what is the same. Color coding in 3 way comparisons (explained below) make it easy to tell whether a passage is different because something was added, or because something was deleted, or because something was replaced. Menu items inside the GoTo menu, as well as the next and previous diff buttons allow you to quickly move between changed sections.

Merges

Merging files also doesn't change any of the files being compared, but it does generate a new file, the merged result. MergeRight has a number of options that can be invoked from the View menu which allow you to quickly select or deselect sections to include in your merged result. Comparison tools like the Symantec Visual Cafe File Compare tool can't do that.

Two way vs. Three way comparisons

Two way comparisons

When comparing two files you can easily tell if a section appears in one file but not the other. But when you see this, you can't tell why the two files differ. Was the section added to the first file, or was it deleted from the second. We can't tell. But often knowing is critical to deciding whether to include the section in a merged result or not. If the section was a new feature, we probably want it included. But if deleting the section was done to fix a bug, we sure don't want to include it again.

Three way comparisons

A common way to tell whether material was added or deleted is to compare to the original file that both are derived from. If the section isn't in the ancestor, it must have been added. On the other hand, if it was in the ancestor it must have been explicitly deleted.

To determine this, instead of just doing one comparison, we must do three. If we are doing three, it is important that we do them as quickly as possible and to minimize the merge work on the user we must generate the minimum number of differences possible. MergeRight uses an implementation of an algorithm developed by Webb Miller and Eugene Myers. Myers has done a mathematical proof that this algorithm most quickly reaches solutions with the minimum number of differences and that no faster algorithm is possible. The Unix file merge command and several others use inferior merge algorithms that can take very long times to process some files and may make more difference sections..

Recommendations

By doing three way comparisons we can actually make recommendations about which code to include in the merge: Things that were deleted should not be included, and things that were added or changed should be included.

Conflicts

Sometimes changes are made to the same lines in both files being merged. When this happens, we say the sections are "in conflict". We can't make a recommendation for that section. Only by looking at the sections in conflict can the user determine semantically how to "resolve" the differences. Often this can be done by copying the changes from each file and pasting them together in the result file. Sometimes it is more complicated and you have to select one side, the other side, or edit right there and create something entirely new. This is sometimes hard to do with other Merge tools, but not with MergeRight. Color coding and menu items make it easy to find conflicts, and the built in editor makes it easy to copy, paste and even edit in place, before the final merge is generated.

Merge/Edit vs. Edit/Merge

Because of conflicts, it is usually impossible to merge without some editing. Traditionally there have been two types of approaches.

Merge/Edit

The first approach, typified by non-visual merges (sometimes called "automatic" merges), attempts to apply recommendations automatically and create a merged result file with no user intervention. If there are conflicts, these are flagged with "comments" in the resulting file and by a printed warning. If there are no conflicts things are presumed to be fine (though this can be erroneous as we explain below). When there are conflicts the user then edits the result file with a text editor and looks for the conflict comment markers and then edits the sections between them until they are okay. This is called the Merge/Edit strategy because first you Merge and then you Edit.

Edit/Merge

The other approach, used by MergeRight and most other visual merge tools, does the comparisons, but does not commit the merge until the user had a chance to edit any conflicts and to detect and fix any semantic conflict problems that may occur.

Theoretically Merge/Edit would be faster because except in conflict cases no human intervention is needed. Unfortunately, automated merges introduce hard to detect problems in a small but important number of cases. Moreover, finding these kinds of problems after the merge has taken place is very hard because there is no longer information in the result file that allows you to tell what changed. For this reason, Edit/Merges are strongly preferred when accuracy is a concern.

Recommended changes and errors in Automated merges

When doing three way merges, MergeRight can make recommendations as to which sections to include or exclude. Usually these recommendations are right, but merges should always be checked to make sure that there are no "semantic" conflicts introduced by the merge process.

While these happen rarely, when they do happen if they are not detected before the result file is written, they introduce subtle hard to find and fix bugs. For this reason, MergeRight's user interface has been designed to improve the capabilities of users to find and fix these semantic conflict problems before they get into the final merge result file.

This is a big difference between MergeRight and other so called "automatic" merges. Those automatic merges automatically apply all the recommendations and don't provide you a way to detect that this will introduce errors or a way to fix them. MergeRight, on the other hand makes it easy to use these defaults but also easy to override them on a case by case basis wherever semantic conflicts are found.

How semantic errors can occur in conflict free merges

The following is just a brief overview. For more complete information on this topic, see our White Paper or contact sales@prescient.com.

Consider the following example:

Imagine that each gray area represents many lines of code that are common in each file. If we do an automatic merge we will get the following result file.

However, when this program runs it won't result in k = 10. Instead the resulting program will have k = 100, even though none of the merge files had that result, and even though no syntactic "conflict" was detected by the automated merge.

Our example is greatly simplified for illustrative purposes, but such semantic errors introduced by automated merges, while rare, still happen with enough frequency and therefore automated merge results must always be carefully checked.

Use of hiding and expanding buttons and ellipses

One important way our example has been simplified is that we have used an ellipsis to compress many lines of code into one. With our example, it would be relatively easy to see that the conditions were occurring that could cause a semantic error, and to correct it even if you were looking only at the result file. And with some comparison tools it would join the 4 differences into 2 8-line conflicting difference areas, so you would be alerted to check the file.

But as the size of the file increases, large common areas can separate each change and it may be hard to see the semantic conflict. This quickly overwhelms "automated merges" and even overwhelms users of most other visual merge tools, as you can't hide the common areas. With MergeRight we realize that putting the changes close together so you can see several of them at a glance could be just what makes it possible to perceive a semantic conflict. So with MergeRight, common areas are typically "hidden" by default or through the use of a hide button or menu item. Hiding reduces them down to a single line marked with an ellipsis, just as in our example above. Clicking the ellipsis button or using a menu item allows you to expand the common area and see it for context, after you've already checked for possible semantic conflicts. This greatly increases the ability of the user to spot and prevent semantic errors from being introduced during the Merge process.

Finding and fixing semantic errors - Continuous vs. Concordance views

Another advantage to the MergeRight user interface is the use of the concordance style view. By "concordance", we mean that corresponding sections from each file are always shown side by side, as in our example above.

MergeRight does this on a section by section basis, whereas other visual merge tools only have whole files side by side in a "continuous" file view fashion. This means that with other merge tools you have to keep unlocking and relocking the scrollbars so that corresponding sections of each file are visible at the same time. With MergeRight, corresponding sections are automatically kept side by side, so there is no need to lock files to keep corresponding parts next to each other. This results in faster and more accurate decision making when reviewing merge recommendations.

We are proud to say that MergeRight was the first and only merge tool to use the powerful concordance style view. It is far harder to program than the continuous style systems -- but far easier on the user.

Use of color vs. symbolic tags

Many merge tools use symbols (e.g. "=", "+", and "-") to indicate which sections were the same and which were deleted. Some use other symbols like "<" and ">" to indicate changes that were in one file or the other when using these tools. It is important to know these things, for otherwise code that was removed intentionally to fix a bug might be accidentally re-inserted in the result file. Unfortunately, symbol processing and symbolic interpretations is a relatively high cognitive load activity. This slows assessment and degrades correct resolution of merge differences.

This applies to more than just merge tools. We respond faster to a red light in a traffic signal than we can to the letters "stop". In fact, we observed that with symbolic merge tools people often misread or ignored the symbols thus introducing errors. With MergeRight, we used colors that are recognized and correctly processed without symbolic interpretation demands on the mind. In fact, we used habits such as color matching in our recommendation mechanism to further encourage people to correctly handle explicitly deleted sections.

Summary: A focus on human interface

Our use of the concordance style view, color matching, ellipses and many other user interface details all reflect our particular view of what a merge tool should be. Until a merge tool can be made smart enough to automatically resolve all conflicts, both syntactic and semantic, humans will need to intervene in and review the merge process. We realize that what is most important is to make the human as effective and productive as possietails all reflect our particular view of what a merge tool should be. Until a merge tool can be made smart enough to automatically resolve all conflicts, both syntactic and semantic, humans will need to intervene in and review the merge process. We realize that what is most important is to make the human as effective and productive as possible, not to make our programmer's job easier. That means focussing on what humans can do well and enabling them to do it with as little confusion or distraction as possible. And it also means focussing on what kinds of activities overload human cognitive tasks and finding ways to minimize those problems. The means to implement these improvements is through the user interface, and at Prescient that has been our main focus.