Features

Language support

SemanticMerge can merge any source code file, independently of the programming language. Merge a Ruby file and Semantic will do even better than more traditional tools like KDiff3 thanks to its Xdiff/Xmerge technology

But Semantic excels when it parses the language. It currently supports C#, Java, C, C++ and PHP, and there are many community contributed parsers available.

Location independent method* merge

The first “mind blowing” feature in SemanticMerge allows you to move your methods around, refactor, and cleanup the code, and SemanticMerge will still be able to resolve the merge because it merges on a method-by-method basis.

In the scenario below, a traditional text-based merge tool will have trouble trying to match “src” and “dst”, matching “method1()” with “method2()”, since “method2()” was moved up on “src”.

SemanticMerge doesn’t really care where “method1()” is, it just knows that it has been modified by two contributors and will place the result in the correct place.

* Applies to properties, classes, methods, namespaces… it is a “structure based” merge and not text-based.

SemanticMerge tool detects the method conflict:

And once the developer merges the method, the conflict will be solved:

Representing the conflict visually turns a complex refactor into a trivial operation: the “Listen()” method has been moved to two different locations and also modified in parallel, isn’t it easy to understand?

SemanticDiff also benefits from the new Visual feature:

Tracks what has been added on a location independent way

Two developers start working from “base” file and then they add a “new_method(){}” in two different locations. During the merge, a text-based automatic merge tool would incorrectly solve the conflict by duplicating the code.

SemanticMerge would detect this situation and let you choose the final location on the destination.

In the case where “new_method()” is not 100% identical, a “two-way” merge of the method can be run to solve the conflict.

SemanticMerge tool handles the merge scenario as follows:

Dealing with language specific constructs: ‘using’ clause in C#

This is not a dramatic scenario, but SemanticMerge can still help, where two developers add the same “using” clause in two different locations.

Regular text-based merge tools won’t detect the fact that the added ‘using’ clause is actually the same, which would typically only be detected at the build phase. SemanticMerge detects that it is the same “using” clause and will add only one of the two clauses.

Method based conflicts – even if text blocks don’t collide

This is a very common scenario for developers: imagine that the same method is modified in parallel, but the modified text blocks don’t collide.

It can turn out to be an unwanted automatic conflict with a text-based merge tool… SemanticMerge knows that it is the same method and can run a manual merge even if the text blocks do not collide.

SemanticMerge detects the method conflict even when the textblocks do not collide:

Running “merge” shows the 3-way merge tool focused only on the conflicting method:

A traditional text-based merge tool wouldn’t have detected the conflict but SemanticMerge does, giving the developer a chance to review the potential issue even if the merge is set in automatic mode (non-conflicting changes set to be handled automatically).

Fully refactor aware

Suppose you move one method to an existing subclass; meanwhile, another developer moves the subclass to a different location within the file and also modifies the method you moved on the original location. SemanticMerge is able to solve the situation and generate the result with no conflicts!

1 “class core” moved to the new location
2 “method2()” moved inside “class core”
3 “method2()” getting the changes made on “dst” directly

Impressive, isn’t it?

The primary advantage is that you can now enable refactoring to occur even if it happens while bug fixing or other development is being done, which means you will end up with cleaner code and it will be much easier to maintain.

Semantic Diff included

Sometimes understanding what happened to a file is far from trivial. You run a side-by-side diff but it’s hard to really understand what was going on with the code.

Semantic Diff is included with the SemanticMerge package and it explains exactly what happened, even when code was moved, methods sorted, classes split, and so on.

Able to cope with divergent refactors

Suppose there is a “StrLen()” method.

The first developer decides to move it to “class Format”.
The second developer decides to create a new class to handle the string related methods.

SemanticMerge will detect a “divergent move” conflict and will let you choose between one of the two moves.

BTW: if the method was concurrently modified, it will invoke a 3-way merge as well.

Move and delete scenarios

Let’s review a different refactor scenario

The first developer moves the “StrLen()” method to the class “Format”.
The second developer decides to remove the “Format” class.

SemanticMerge is able to detect the “move/delete” conflict, and help you resolve it. You will have the choice to keep the delete or the move.

SemanticMerge fallback mechanism

SemanticMerge relies on code parsing. If any of the 3 files involved in the merge can’t be parsed, SemanticMerge won’t be able to proceed. If this happens, the fallback text-based merge tool will be launched*.

You can also revert to text-based merge once SemanticMerge has been launched, by clicking on “run merge tool”.

*When you run SemanticMerge you’ll need to specify a 3-way text-based merge tool to deal with text conflicts. The SemanticMerge installer includes the default’s Plastic SCM mergetool known as Xdiff/Xmerge but you can setup any tool you prefer such as KDiff3, Araxis Merge, or others.

Xdiff and Xmerge

A feature to deal with refactored code at a text level, in a programming language agnostic way. Xdiff/Xmerge stands for “cross diff” and “cross merge”.

Diff moved fragments of text

Identifies fragments of code that were moved. Even if the code was changed after, Xdiff still detects the move.

When Xdiff compares two files, it draws a link between the code fragments. You can navigate between the fragments or display the differences between the fragments in a separate window.

And merge moved code… even if it is not one of the supported programming languages

Xmerge detects code that was moved by one developer while modified in the original location by another.

The moved code is then merged with the changes in a separate merge window, easing the process and often resolving this complex scenario automatically.

These two blog posts on Xmerge have additional information and include screencasts:

Try it free for 30 days