SemanticMerge 2.0 is out now
SemanticMerge just turned 2.0 and we’re all very proud of it. It is the first major release since we launched the product back in 2013.
2.0 features a totally redesigned user interface that makes it more suitable for daily use. Now it is not just the tool you use to handle tough merges. Thanks to the new design it is now the tool you can use on a daily basis for a wider range of scenarios. It is more intuitive and easier to use.
We have created a new UI from the ground up
We have totally redesigned the user interface. Version 1.0 was all about the core, about being able to deal with refactored code, but the UI ended up being “too alien” for many users. It had nothing to do with the traditional layout of a 3-way merge tool.
The layout of 1.0 was as follows:
There was a big panel to solve semantic conflicts and a text editor on the right to switch between the 3 contributors. We built it this way because we still didn’t have a good solution to show methods that were moved and modified in a 3-way layout. The tool was obviously useful, but it lacked the familiarity of traditional tools for many users.
The 3-way merge layout is as follows:
The 3 panels on the first row represent, in left to right, the “source contributors” (a.k.a. “theirs”), the “base” (a.k.a. common ancestor) and the destination (a.k.a. “yours”). The panel on the bottom contains the “result” (in some merge tools they use a 3 panels in total, mixing “yours and result” together. To find more about the layout of merge tools, read this).
SemanticMerge 2.0 sticks to this new 4-panel pattern used by most of merge tools, which results in a much cleaner and clearer interface, that is more familiar for newcomers.
2.0 in action
Let's now see how this redesign actually looks like. Check the following merge scenario. The figure is actually taken from the Semantic 2.0 “visual merge” feature:
You see how the method “CheckChangesets()” has been “changed” in the two contributors, and one of them also decided to move it down.
Just to make it even clearer, check the following figure:
So, when merging the file with a traditional text based merge tool, it will have trouble dealing with “CheckChangesets()”, because you moved it down, so it will probably try to match the content of this method on “base” with the one that is located where “CheckChangesets()” used to be… creating a big mess.
In SemanticMerge 1.0 we were already able to solve this conflict, but we just showed something as follows:
Which was fine to solve the conflict, but it didn’t really show the actual code, so it was like a huge change compared to what most users were used to.
(Note: this panel is still available in 2.0, and shows up on the left of the code editors).
And that’s how 2.0 handles the case:
Check how the tool is able to align the 3 contributors even when one of them is not even close to the other. It does that by “resynchronizing” the code editors for the current method in conflict.
This radically changes the way in which Semantic 2.0 works, because now it provides a much more familiar experience, combined with all the Semantic power.
You can see how the code is now decorated with the “change” icons (changed, moved, deleted or added) as the following full screen picture shows:
Watch it in action
Want to see it in action before you try? Ok, just watch the following screencast where we explain how to deal with a divergent move merge... not an easy one, by the way :-)
Get it now
You can download SemanticMerge 2.0 from www.semanticmerge.com and evaluate it free for 15 days, or 30 if you register on our website!