Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-03-21 13:38:18

> -----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.

Paul

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