Category Archives: semanticmerge

Visual merge representation with SemanticMerge

Since my last blog post about the SemanticMerge software (actually the last post I wrote until now) end of April 2013, the team behind the software didn’t sit still.

Next to C# the tool now can read and understand VB.NET (looks logic, it make use from the same Rosylin project to compile like C#) and JAVA.

I’m hardly write any code and those languages so I lost track of the latest developments of the codicesoftware team until I received a tweet to attract my attention to their latest release.

What’s a visual merge representation?

Was the first question that raised my mind after reading the title of the blogpost “SemanticMerge goes Visual”. The first picture already revealed a bit of the answer.

imageNext to the textual representation, that already existed in the previous versions, where you get a list of detected changes in the source and destination file.

In the screenshot on your right you’ll see they make use of symbols to decorate a change ( C ), a move ( M ), a renaming ( R ) or deletion ( D ) in source or destination file.

It’s gives you a readable and logic overview before you start merging the files together.

The Visual representation will extend the textual view. Instead of a list of changes you’ll get the 3 files that are compared during a merge (source, base and destination).

image 

Watch especially the same symbols that were used in the text overview. On the base class you’ll see that they placed the symbols at the side where the change was.

image

Together with the arrows drawn to guide the change you’ll get a pretty good overview of the merge changes that were discovered by the software.

Remarks

Although I like this representation to help you understand what is being merged there are some areas where some improvement can help the end user.

Unchanged items

The examples that were installed with the software have classes and methods that all were changed, moved or deleted. It’s a perfect way to show the merge capabilities of the SemanticMerge tool but for the visual representation it hides the unchanged code that in a real life example will be there (we hardly refactor the whole file at once).

image

The screenshot on your right shows a test class we have made to test some of the functionality without having to implement WCF services that would be used to access the final code.I just took a diff in this example (using the SemanticMerge diff viewer that also supports the visual view)

Only a few methods are changed, they get lost in the many unchanged methods or code.

This is the default view when opening the visual representation. You have a few buttons on top to hide the unchanged items or to group them so you’ll have a better view. Why not making that the default presentation. How many developers are interested in code that didn’t changed when they are merging branches together. My attention always go to the changes and verifying that those are merged correctly in the destination file.

image

image

I think it would be better to have the end user choose their default view when merging.

image

Leave the buttons on the top so we can switch when necessary but don’t let us click to much to reach our goal.

Picture size

The first time I opened the Visual view it was big, too big. it really slammed me in the face, and on top of that, the picture was to big for the opened window so I had to use the scrollbars to get a complete view.

The view support zooming by the ctrl key and the mouse wheel but I couldn’t find a zoom button or slider (handy when working on a laptop without external mouse). Nor did the combination ctrl key and the plus or minus key worked to zoom.

Make the diagram fit the window (even a bit smaller) and together with the hidden unchanged items would make it a lot better.

Go to change

When you select a change in the textual view you’ll have the choice to view the code on source or destination or the differences between the two depending on the change.

image

I can’t find the same functionality in the visual view. You can select the change but clicking or double clicking did nothing. I thought it would bring me to the correct place inside the code file of the source, if clicked on the source or the code file of the destination if I clicked the destination representation.

Now I can see that a certain method is changed but I have to go back to the textual overview before I can view the source (or destination) code block.

Hidden functionality

I find the visual representation a bit hidden in the SemanticMerge tool. Ok, the button states “Visual Merge” but wouldn’t a small preview of the visual presentation attract more users to use the presentation? Be proud on what you accomplished, a bit showing off wouldn’t hurt anyone.

image

Conclusion

I definitely find a visual representation of the merge path a big plus in a merging tool. Certainly when there are a bunch of changes on the file (changes, moves, deletions, …) the visual view will help you understand what will be merged.

Just as last time I’m impressed by the fine work of the team and how they change the way of merging code away from the painful process it used to be.

Some small changes (see above) would make the software a lot better and ready for use.

Take a look for yourself, download SemanticMerge, use it today, you’ll find it very handy especially in larger teams!

Semanticmerge diff viewer settings for SVN

Last week I blogged about the new merge tool that understands your code and helps you fight the merge agony when working with multiple developers on a project.

Diff viewer

The semanticmerge tool doesn’t only helps you with merges, you can use their diff viewer to compare the changes you made on a file, or compare the changes you made against any version in you source control.

Setting Tortoise SVN options

To use their diff viewer we’ll have to tell Tortoise SVN witch files he have to compare. Right click on a folder and choose for ‘TortoiseSVN’ and then settings.

In the settings screen go to ‘External Programs’ – ‘Diff Viewer’. There you can set the path to the semanticmergetool.exe.

image

For the diff viewer we’ll only need to set 2 options. The ‘base’ file and the ‘mine’ file (where the changes are. The complete command:

Testing

After saving these settings in TortoiseSVN we can start testing. Open up one of your code folders and right click on a file you’ve changed.

image

Click on ‘TortoiseSVN’ – ‘Diff’ and wait a second for semanticmerge to come up. One of the advantages of the semantic diff viewer is that you immediately get an overview of the semantic differences on the left hand side.

image

You’ll see directly if parts are moved or changed. You can click on one of the changes and click on the diff button to only see that change.

image

image

Or you can click the launch diff tool so you can scroll through your file and see all changes. You still have the option to open the specific change in the overview.

Conclusion

I was already impressed with the merge tool an sigh but the also the diff tool has some advantages you don’t find in the basic Tortoise diff viewer.

DISCLAIMER: The configuration seems to be working on my system. I’m not 100% sure it’s the correct configuration. Use it on your own risk!

New merge tool Semanticmerge, tested on SVN

This morning I saw a post of Scott Hanselman passing by on facebook:

“There’s as new code merging tool in town… “Semantic Merge – Plastic SCM” http://t.co/mlaqWnVGST Free Download of the Beta”

The welcome text on their site is very promising:

“a semantic merge tool…
that understands your code”

A project we’re working on at work is in a phase of a lot of refactoring’s. the base functionality seems to be working fine, we’re now taking care of better fault handling, better logging, better messaging, …

That includes a lot of refactoring’s, moving methods, adding log messages, updating methods in a team of 3 developers. That results in a lot of merge errors as we more then once make changes to the same files in the project.

The default text merge tool can’t handle these changes and more then once we’ve been fouling around for over an hour to get the files back to a ‘working’ state.

No SVN documentation

We still work with SVN for our internal projects. For my personal projects I’m hooked up to git in combination with GitHub as you probably can see in the different topics I blogged about before.

The guys from Semanticmerge placed some documentation how to configure the merge tool for git, TFS and Plastic SCM but they didn’t include documentation about configuring TortoiseSVN (the tool we are using).

On their UserVoice page there’s already a request for documentation on SVN and Tortoise.

Trial en error configuration

I didn’t wanted to wait for the upcoming documentation and decided to try and figure it out myself. I took the documentation for TFS for the semantic mergetool, the Diff/Merge configuration documentation on  MSDN, the Tortoise documentation (search for merge tool) and a post on stackoverflow to combine the different parameters that have to be set.

After some attempts I think I got it running.

Setting Tortoise SVN options

First start with downloading the beta of the Semanticmerge tool and install it on your system. You’ll need the location where you installed the tool, note it during installation or you’re going to have to search your system for the executable needed in the next step.

In TortoiseSVN you can set the merge tool you want to use (default TortoiseMerge), this we’ll have to change to the semanticmerge tool. Right click on a folder and choose for ‘TortoiseSVN’ and then  ‘Settings’.

image

In the settings screen go to ‘External Programs’ – ‘Merge Tool’. There you can set the path to the semanticmergetool.exe.

image

If you would try to merge now you’ll get an error message. The tool will be started but it doesn’t know witch files he have to merge. Those parameters will we have to add after the path to the executable.

After some searching I added following options:

So the complete command you have to fill out for the external merge tool:

Testing

I’ve created a test class with 3 simple methods and committed this to our SVN server.

On one virtual machine I updated the source and added some changes in the file. I moved the second method under the third method and added some dummy code.

I then committed the file back to the server. On my machine I also changed the same file. I’ve added a test class under the existing class and added some dummy code to the second method (that is still the second method in row).

When I then update my code on my machine I’ll see we have some merge errors (like expected).

image

If you then click on ‘Edit conflict’ the merge tool appears.

image

It indicates that Method2 is changed on both contributors. You can click the merge button to view how the tool automatically merge the files.

image

The moved method is nicely merged with the changes of the not moved method. Just like we wanted. The merged result:

Conclusion

At first sight (the merged class wasn’t that difficult) the tool does what it has to do. I’m going to start using it on our project now and will see if some more complex merges will have the same result.

One of the problems I’m still facing is that for SVN the file doesn’t seems to be resolved automatically. I still have to find the file and right click and choose ‘resolved’. Or you can do that on a checkin but then you have to remember witch files you’ll already merged.

It can be it’s another parameter you’ll have to add to the command line expression but I couldn’t find any documentation.

DISCLAIMER: The configuration seems to be working on my system. I’m not 100% sure it’s the correct configuration. Use it on your own risk!

UPDATE: You can also use the samentic merge tool as diff viewer in TortoiseSVN.