Re: [boost] [Git] Documentation for Git and Modular Boost conversion

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. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo