Is there an intelligent 3rd merge tool that understands VB.NET

Question

I am having problems with our merge tool as sometimes it fails to match the unchanged blocks in the two branches correctly. When this occurs the merge tool becomes useless, and the merge has to be done by hand.

Therefore I am looking for a tool that:

• Understand what VB.NET function/method definitions looks like and gives them a high importance when matching blocks.
• Knows that VB.NET will change the case of fields etc, whenever it feels like it, and therefore ignore differences in cases when finding the common blocks, but still merges the difference in case.
• Knows that ‘ and ‘// are both start of comments and will match them when finding the common blocks

Also what other requirements have I forgotten?

(The problem we are having is that our merge tool (Guiffy part of SCM source code control system) is written in Java, so has been tested well with Java and seems to work well in “real life” with our C# code, but it does not get on us well with our VB.NET code.)

Answer 1

I use WinMerge pretty much exclusively now, I find it better than the Merge in Tortoise SVN and apparently it supports VB.Net.

I don't know if it can understand field cases and so on, but it's pretty powerful, so might me worth a try.

WinMerge.

Answer 2

Merge tools understand files and differences in files, they do not understand languages and the differences between them.

As most languages do make a distinction between upper case and lower case variables, this is how most merge tools will work. This is also true for VB.NET key words (If, Then are OK, if, then are not), so even if it were to ignore case it may not work well for you.

Personally, I use the perforce merge tool (p4merge).

Answer 3

p4merge is pretty awesome, and is available for free at perforce.com.

I don't know if it understands VB.net well, but it is a great tool.

Answer 4

Araxis Merge which i'm currently evluating supports Ignore Case option.

Answer 5

Answering the comment by Ian Ringrose "but why can't a merge tool understand a given language?"

There is a mismatch between the concepts of having source code in text format an having code as an AST (Abstract Syntax Tree), even if there was a representation for source comments in AST.

What you are looking for, is an IDE which would store code as an AST representation in XML format. Then just any text oriented merge tool would work for you, not only a Visual Basic specialized one. XML is the one format where merging an interpreted source makes more sence then merging the source code.

As for general practices in case sensitive languages, formatting makes sence in terms of code reviewing, reformatting the code is classified as a refactoring, and it generally must be taken into consideration in version control process. One of the reasons for that, is that code formatting and even encoding and carriage return settings of source files actually affect the project, not only the AST generated from the code. Code could contain metadata in comments, can be processed by a runtime procedure, which could depend even on the encoding and line ending settings. For example, an ASPNET website html output depends on the character encoding, you output could coume out garbled if you misuse it. A third party tool processing the code could fail, if it's parser can't deal with a carriage return which is considered good for Microsoft compiler.

That is why merge tools mainly treat every character change as a real change, and even whitespace makes difference, even if you have an option to ignore it.