Channels ▼

Pablo Santos

Dr. Dobb's Bloggers

Live merge, merge to live. Part II

December 29, 2008

 This is the second part of the series of articles about merging. In the previous post I talked about automatic merges and how the version control systems solve the conflicts for you. But, whenever you start thinking about merging you'll say: "hey, what if we touch the same code?". I'll try to answer this question here.

You're in trouble: manual conflicts

Developer's life can be exciting and full of challenges, but it is not easy. So, eventually you'll face a situation like the one depicted here:

 

Figure 3. A conflict on the same code block

Yes, know we've modified exactly the same code in one of our changes on the file, which makes things much more complicated.

Now you can say "the tool can't know the right solution!".

And you're right. But, as I told you, the merge tool is not a wizard's device; it is just a programmer's tool. So, use it correctly and it will make your life much easier.

Figure 4 shows a merge tool in action letting you decide what to do with your manual merge conflict.

 

Figure 4. Merge tool solving a conflict

Under these circumstances the tool will always prompt the user. It will still save you precious time because it directly focuses you on the problem, but you'll have to make the decision yourself.

So, the merge tool will help you with automated conflicts not even asking you if you don't want to (and honestly, it is the right choice) and will ask you for help whenever it finds a manual conflict, which is basically a code fragment with changes made by two developers at the same time.

The rule of thumb is very easy and will help you trust the tool because there's no complex code analysis behind: just looking into the lines of code: if only one contributor changed the fragment, it is an automatic conflict, otherwise, it is not trivial and the tool will ask.

2-way and 3-way merging

What's all this fuss about 2-way and 3-way merge tools? What are they all about? Ok, that's what I'll be explaining in the next paragraphs: it basically depends on the number of file versions you consider for your merge operations.

So far, what you've seen is a 3-way merge in action:

  • You have the original file: it is the file as it was at the beginning before a specific set of changes is performed by our developers.
  • Then you have the file you have modified (remember the previous samples).
  • And finally the file I've modified.

The result file is the one created after the changes are combined, the one at the bottom at Figure 4 (some tools prefer to hide the base file and just show the result one).

I didn't explain 2-way merge yet, but it is not very complicated: it doesn't consider the base file for the merge.

Is it better? Simply put: no, it isn't. 3-way merge knows what you've added or removed to a file while 2-way merge can't because it doesn't know how the file was at the beginning.

But, still, I've found developers who seem to be more used to 2-way merge tools. Let's try to figure out why.

Let's go back to the original Java file, make a couple of very simple changes, and try to merge them with a two-way merge tool. Check the results on Figure 5.

 

Figure 5. Running a 2-way merge tool

See the problem? Basically, at each difference the 2-way merge tool won't be able to decide whether it is modified or remove code, so it will always have to ask you!

This is good for the paranoid but, believe me, if you've to manage a good number of merges, you'll end up wasting your time.

The same two conflicts would be automatically solved by a 3-way merge tool.

Of course, there's a remark here: you can only use 3-way merge with a version control tool handling your code. Otherwise you won't have access to the base file unless you've a very good memory or a crazy naming convention to keep your old files...

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video