Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-02-09 17:32:06

On Thu, Feb 9, 2012 at 11:54 PM, Steven Samuel Cole
<steven.samuel.cole_at_[hidden]> wrote:
> Edward Diener wrote:
> releases have failed because of this - code builds fine in dev branches, but
> once it's all merged, nothing compiles. this integration problem is one of
> the reasons why the whole continuous integration concept has come up in the
> last decade, see http://en.wikipedia.org/wiki/Continuous_integration.

This link doesn't help your case at all:
" Extreme Programming advocate Martin Fowler also mentions that where
branching is supported by tools, its use should be minimized.[4]
Instead, it is preferred that changes are integrated rather than
creating multiple versions of the software that are maintained
simultaneously. "

If you don't branch a lot, you probably don't need git.

(My personal experience strongly supports this, by the way. My former
company used continuous integration this way with great success,
though, they were projects very different from boost in its nature).

> git circumvents this problem to some extent by anticipating the need for
> branches and merges as a central concept and incorporating it on a much
> lower level than svn; branches are much more lightweight and are possibly
> created and merged back in several times a day.

Branches _are_ lightweight in SVN (constant time). On the other hand,
it is true, that their _usage_ is probably heavier weight than in git.
Now, I don't see the use for so many branches. I see an overhead in
using them though, because however efficient the tools may be you
still need to think about your branching and perform some (however
simple) manual operation.
I would quote Python guys: it's easier to ask forgiveness than
permission. I work on my trunk at all time, if for some reason I make
a mistake, it's not too hard to cancel it.

>> Steven Samuel Cole wrote:
> I also found I had to let go of my conventional understanding of source
> control systems: In contrast to a central svn server where one single
> head revision is pushed forward by changes from the team, git feels to
> me more like sets of changes are passed around between local repos
>  - and one of them - one that gets special TLC - is the master branch.
> Does that makes sense ?

I think that this (and local commits that SVN may get in the form of
checkpoints in 1.8) is the one good reason to consider switching to
git. Though changing the philosophy of working of many people is a
huge roadblock. Boost has been committed to quality and wishes to make
frequent releases leaving not much room for such a switch.
To see whether this is good or not, well I guess you have to be an
active boost developer (which I am not) and know patches actually flow
around (andI don't).

Julien