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.
What it does?
SemanticMerge tool detects the method conflict:
What it does?
And once the developer merges the method, the conflict will be solved:
What it does?
What it does?

Visual Merge and Diff

Our goal with SemanticMerge is to encourage teams to refactor their code without fear because the tool will be able to merge them.
To merge (and diff) efficiently you first need to understand how the code has been modified, and sometimes there is nothing better than a good graphic. And this is what Visual Merge is all about.

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?

alttitle
SemanticDiff also benefits from the new Visual feature:
alttitle

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.

alttitle
SemanticMerge tool handles the merge scenario as follows:
alttitle

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.

Dealing with language specific constructs
Dealing with language specific constructs

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.

Method based conflicts
SemanticMerge detects the method conflict even when the textblocks do not collide:
Method based conflicts
Running “merge” shows the 3-way merge tool focused only on the conflicting method:
Method based conflicts

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.

Fully refactor aware
Fully refactor aware
Fully refactor aware

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.

Semantic Diff included
Semantic Diff included

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.

Able to cope with divergent refactors
Able to cope with divergent refactors
Able to cope with divergent refactors

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.

Move and delete scenarios
Move and delete scenarios

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

SemanticMerge fallback mechanism
*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.

Bonus track included in the package – Xdiff and Xmerge tools

SemanticMerge includes the text-based Xdiff and Xmerge tools that are able to deal with refactored code at a text level and hence, become the perfect companion for the structural merge provided by SemanticMerge.

Detect code that was moved

Xdiff and Xmerge ("cross-difference" and "cross-merge") identify fragments of code that have been moved and link them for easy navigation. They use a similarity algorithm that identifies fragments of code that have been modified within a user-specified threshold. Even if the code was moved and then changed, it's still detected as the same block of code.

When Xdiff compares two revisions, 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.

Bonus track included

Merge refactored code seamlessly

Xmerge can detect code that was moved by one developer and 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:

Bonus track included