Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-22 02:59:34

Thomas Heller <thom.heller_at_[hidden]> writes:

> On 03/21/2012 06:38 PM, Paul A. Bristow wrote:
>
>> Well both in working collaboratively on Boost.Math and a couple of
>> GSoC projects, I have found that coming to commit and finding that
>> someone else has committed a change is common.
>>
>> Unless you agree who has temporary exclusive access to the code, it
>> is all too easy to find that changes collide.
>>
>> I'm unclear how git alters that (if at all) I have yet to understand.
>
> Same here ... But if we believe the git advocates, resolving those
> conflicts is easier with git.

That's actually not true. DVCS tools are not magic and when there is a
genuine conflict in SVN (the same region was editited in parallel by two
developers) then you also get a conflict in Git and Mercurial.

The difference is that Git and Mercurial track the history more
explicitly in their changeset graphs -- SVN has merge tracking after
version 1.5, but according to the SVN authors, it's a fragile feature.
I've heard from clients that they migrated to Mercurial after finding
that Subversion had conflicts in the *meta data* that was supposed to
track merges!

> From what i understand it is partly due to the fact that gits merge
> algorithm is slightly better than svns.

True, Mercurial and Git has a clearer picture of what's going on. I've
already presented a case where Subversion fails to merge cleanly but
Mercurial and Git will:

  http://stackoverflow.com/a/2486662/110204

In the scenario, there is a rename on one branch and a modification on
another branch.

> This might also be due to the fact, that commits are broken into
> smaller pieces, thus the conflict is more isolated.

No, the number of commits is not important for a three-way merge. This
is a very common misunderstanding, though, and many blog posts keep
saying this since it sounds intuitively correct.

But the fact is that a three-way merge is concerned with three things
only: common ancestor, your version, and my version. The number of
commits that went into producing your and my version is irrelevant.

I've written a little about it here:

  http://stackoverflow.com/a/8592480/110204
  http://stackoverflow.com/a/9500764/110204

-- 
Martin Geisler
Mercurial links: http://mercurial.ch/