9 Feb
2012
9 Feb
'12
10:32 p.m.
On Thu, Feb 9, 2012 at 11:54 PM, Steven Samuel Cole <steven.samuel.cole@gmail.com> 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