Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-03-22 03:36:09

On 03/22/2012 07:59 AM, Martin Geisler wrote:
> 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
>
Thanks for the clarifications!