Boost logo

Boost :

Subject: Re: [boost] [git] neglected aspects
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-02-28 15:03:12

on Wed Feb 08 2012, Daniel James <> wrote:

> On 8 February 2012 14:37, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
>> This might have been mentioned before, but gitflow seems to be ideal.
>> See [5] for an explanation of the branching model and [6] for an
>> optional tool which automates workflows that adopt the model.
> The problem that we face with something like gitflow is testing. We
> only have the infrastructure for testing two branches so we can't
> adequately test feature branches. We really do need to test on a wide
> variety of platforms as early as possible.

The way we plan to handle this with Ryppl is that you check in a testing
specification with your project. The testing specification is just a
text file, something like this JSON:

    <configname>: {
      dependencies: { /* dependency versions */
        <libname>: <git tree-ish>, ...
      cmake: { /* properties passed to cmake */
        <key>: <value>, ...
      platforms: [ <platform-string>, ... ]
    }, ...

Where you can request multiple configurations to be tested for commits
on each branch. To get your in-development work tested, just publish a
feature branch containing a test specification file to your public

The test results are then added to the commit using git notes.

> But we wouldn't want to merge half done features into the develop
> branch just to get testing (this is one of the biggest problems we
> have at the moment, changes are often in trunk for some time before
> they're merged into release, if at all).
> A possible solution would be to use the 'develop' branch as the
> equivalent of our current release branch

I take for granted that we're going to have a modularized boost with a
separate repository for each library (<>)
and each library will have its own develop branch.

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at