Look at the following example:
You have a “Socket class”, and then another developer decides to sort the methods in visibility order (because he just read “Implementation Patterns” or something), while yet another developer needs to modify the “Send” method.
Try to merge this with text-based 3-way merge tools. You’ll get a horrible merge, something you can’t cope with. You’ll need to go and manually place the “Send” method inside the reordered “Socket” class.
But what if the merge tools were able to “parse” the code, then understand that “developer 2” just reordered methods and “developer 1” modified “Send”? Well, a nightmare merge would turn into an automatic one.
Enter a new kind of merge toolWe’ve been working on source code merge technology for a while now. We believe that good branching needs extremely good merging, and that having the two lets your team implement cleaner and higher quality code, making everyone happier from coders (who like to feel they’re doing things right) to sales (better code means lower maintenance costs).
That’s why we’ve created a merge tool that is “programming language aware” and hence it “understands your code”.
And we’re looking for feedback!
If you want to become one of the first coders to give a try to the tool, visit our “teaser page” and grab a beta.
The long story: "... But it should understand the code!"Whenever I get the chance to introduce “file merging” to a developer who is not familiar with it, his first concern is: “Hey, but how is this going to understand whether the changes collide or not?” Then I explain how the 3-way merge works, how it is able to solve conflicts automatically if the same lines were not modified in parallel, and so on, and then they tend to buy the idea.
But their first gut feeling was: “It should understand the code”.
The funny thing here is that if you ask someone experienced in version control, familiar with the state-of-the-art in merge technology, he will explain why text-based merging does a good job and why you can trust 3-way merges. His original gut feeling just sort of vanished.
Sometimes interesting points arise: “What if two developers modify the same method in parallel? I touch the beginning and you touch the end of the method…. The merge may be automatic but it’s also incorrect!!”
The Merge PanaceaI wrote about “code aware version control” long ago but more interestingly the well-known Martin Fowler did it too in his famous “Semantic Conflict” blog post.
Very recently I found a post from ThoughtWorks’ Paul Hammant titled “Features I would love source control tools to have” where the number one feature is “Semantic Diff/Merge”. He seems to be reading my mind when he wrote:
”source-control tool[s] at the top level, should also be able to understand ‘method rename’ (and other refactorings), rather than a series of adds and deletes. Another example is ‘method reorder’ where one method/function is moved below another. There are many others that are closer to our understanding of refactoring operations.”
We’ve been thinking about a merge tool being able to do these sort of things for years. We started with XDiff/Xmerge, tools able to detect code that has been moved inside a file, as a first step towards our “final” goal.
Making Things a Little Bit More ComplexLet’s now go for the next merge scenario that comes to everyone’s mind: What if you split a class moving and modifying methods?
Take a look at the following figure:
- You have a “Socket” class
- Developer 1 goes and creates a new “ClientSocket” class and moves a couple of methods from “Socket” into “ClientSocket”. Then he modifies the “Send()” method.
- Meanwhile Developer 2 goes and creates “ServerSocket”, moves two methods there, and finally renames “Socket” to “DNS”. Then he modifies the “Send()” method.
Nightmare is the word that comes to the mind of the coder doing the merge of the two files.
But, again, what if the merge tool was able to parse the code and see what happened?
Well, you’d get the resulting file with the 3 classes... automatically. And the conflict in the “Send()” method will be detected and you’ll be prompted to solve it independently of where the method is located.