Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-03-21 13:50:40

On 03/21/2012 06:38 PM, Paul A. Bristow wrote:
>
>> -----Original Message-----
>> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Steven
>> Watanabe
>> Sent: Wednesday, March 21, 2012 4:39 PM
>> To: boost_at_[hidden]
>> Subject: Re: [boost] [git] Mercurial?
>>
>> AMDG
>>
>>> You were given a pretty simple explanation in the previous post.
>>> You cannot commit in SVN without updating first.
>>>
>> Only if some of the files that you modify have been modified in the repository.
>>
>>> For an analogy in parallel programming, SVN requires a global barrier
>>> every time you need to do something, while Git doesn't.
>>> Surely you can see that Git scales much better.
>>>
>>> Now, if you do very large commits anyway, scalability at this level
>>> doesn't matter so much. But good practice is to make relatively small
>>> commits, one commit being a meaningful atomic feature. Small commits
>>> make it much easier to trace the development that has been done, to
>>> identify when problems were introduced, etc.
>>>
>>> Git enables to do many small commits easily without synchronization
>>> with the master repository. It not only improves development time, but
>>> quality of the history as well.
>
>> This is only a problem in SVN if multiple developers are working on the same files at the same
> time.  I don't
>> see this happening a lot for Boost, given our total man-power, average file granularity, and total
> code
>> size.
> 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.
 From what i understand it is partly due to the fact that gits merge 
algorithm is slightly better than
svns. This might also be due to the fact, that commits are broken into 
smaller pieces, thus the conflict
is more isolated.

>
> Paul
>
> ---
> Paul A. Bristow,
> Prizet Farmhouse, Kendal LA8 8AB  UK
> [phone]  07714330204
> pbristow_at_[hidden]