RE: basic Mercurial merge “conflicts” tool

[BOGGESS Rod CORE]

[Tenova]

<http://www.tenova.com>

<http://http://www.tenova.com>

Tenova: advanced technologies for the metals and mining industries
Visit our website at www.tenova.com<http://www.tenovagroup.com/>

________________________________

Confidentiality Notice : This message, together with its attachments, contains strictly confidential information and is intended only for the addressee identified above, who is the sole party authorized to use and copy it and, assuming any related liability , to forward it to others. Anyone receiving this message by mistake or reading it without authorization is hereby notified that storage, reproduction, disclosure or distribution of the message to persons other than the addressee is strictly forbidden. They are asked to return the message immediately to the sender and to erase the original message received.
Thank you.
From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Pietro Moras
Sent: Tuesday, February 04, 2014 7:08 AM
To: mercurial at selenic.com
Subject: basic Mercurial merge “conflicts” tool

I kindly ask suggestions about what's the best basic off-the-shelf Mercurial configuration for facing possible merge “conflicts”.
Reason is I'm not yet ready to face this matter in all its complexity. Thanks!
 - P.M.

I use TortoiseHg, and this may be slightly different from the command line. That said, most merges are done automatically. If Mercurial doesn’t see a change within three lines of another, it simply shoves them together and calls it a merge. That has never been the wrong thing to do.

The very first time two of us changed the same code-line, the messages thrown up were very confusing. I just wanted to exit without screwing everything up irrevocably, and that wasn’t an option listed on any button. In fact, all of the intermediate merge work takes place in the working directory only – meaning, if you just exit without doing the final commit, you can easily update and discard changes to either head. Once you realize that, you’ve nothing to fear. If you get confused, just exit without doing a commit. You can manually edit the code with your favourite editor and do a commit (which will finish the merge), or you can update to either head and attempt a merge again.

I’ll mention here that Beyond Compare can do a three-way merge, and consistently receives the highest reviews among programmers. I’ve never used it. Kdiff3, though, is awesomely powerful, free, ranked closely to Beyond Compare, and I wish I ran into more merge conflicts so that I could gain more experience using it. I won’t say that it’s intuitively obvious how to use it, but in most cases, you’ll just be doing a manual edit while comparing the four versions of the file (common parent, change a, change b, and your results). There is a kdiff3 manual<http://kdiff3.sourceforge.net/doc/>, and there are reasons to read it, but there will be so few times that you need it, I doubt you’ll commit its most powerful commands to heart.

For example, the differencing engine usually aligns based on a minimal match threshold over three lines in either direction. Occasionally, it gets lost and aligns incorrectly. You can force Kdiff3 to align manually and produce a much more meaningful and simplified merge. In the past two years, this has happened to me once. It was awesome to see it in action – thousands of lines of changes, reduced to about a dozen, with a few clicks of a mouse. Seriously, it was jaw-dropping.

Now, all that said, the toughest thing about doing a merge is understanding the nature of two changes. For example, if Alice is implementing a new feature to add lines to a report, while Bob is correcting a bug in the reporting function that resulted in a miscount of the original lines, no merge tool will have the deep insight required to ask, did Alice recount, or just add to the existing count the number of lines she added? As such, blindly applying merges, just throwing lines together, can occasionally be the wrong thing to do. You should be able to contact the two developers should any such questions arise, and you should have some testing criteria (preferably automated) to determine if your merge was truly successful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140204/97497c49/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image0c8183.JPG
Type: image/jpeg
Size: 16909 bytes
Desc: image0c8183.JPG
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140204/97497c49/attachment-0002.jpe>