Boost logo

Boost :

Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-12-07 15:59:11

On Fri, Dec 7, 2012 at 2:25 PM, Eric Niebler <eric_at_[hidden]> wrote:

> (cc'ing boost-steering ...)
> On 12/7/2012 12:09 PM, Michael Fawcett wrote:
> > On Fri, Dec 7, 2012 at 2:46 PM, Rene Rivera <grafikrobot_at_[hidden]>
> wrote:
> >> On Fri, Dec 7, 2012 at 1:25 PM, Eric Niebler <eric_at_[hidden]> wrote:
> >>>
> >>> Once the switch is made, subversion will be made read-only. It won't go
> >>> away, but development will take place in the modularized git repos.
> >>> Changes from git won't be pushed back into svn; that would become
> >>> increasingly difficult as the structure of the repos diverge. Anybody
> >>> who makes use of svn externals to track boost development will need to
> >>> update to git.
> >>>
> >>> Is this scenario common enough that we should have a documented
> >>> migration path for such people?
> >>
> >> Since I'm one of the persons under that scenario my biased opinion is
> that
> >> yes it's common enough. But obviously I don't know how widespread the
> >> scenario is.
> >
> > I've since moved on to another company, but at my last job at least
> > three projects I worked on had a similar setup. They wouldn't be
> > affected though since the externals were set up to the /releases/
> > directory and grabbed a certain tag (e.g. boost 1.41.0). I think this
> > is probably the most common externals scenario.
> >
> > It seems the only people immediately affected would be those with
> > svn:externals to boost/trunk, which seems like an unlikely scenario.
> That seems unlikely to me also. Rene?

I'm in that scenario for a bunch of my projects.. More specifically.. I
track BBv2 from trunk as I use it as my build system. There might be others
who track trunk versions of other individual libraries and tools. Don't
really know though.

> > Those with existing externals wishing to upgrade to the latest boost
> > release would need that migration path, however.
> This could be accommodated easily, I think, but it's something we'd have
> to add. There will be a script used by the release managers to
> reassemble a monolithic boost from the modules for a release. All that
> would be needed would be to run that script nightly and push the results
> into a separate git repo for people to track. Naturally, that repo
> should be read-only for everybody except the bot executing the script.

Since, IMO, one is more likely to track trunk or release versions of
individual parts of Boost.. Would it be helpful to have that same support
be optionally provided?

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

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