Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-12-11 19:01:40


At 08:14 AM 12/11/2002, David Abrahams wrote:

>"Joel de Guzman" <djowel_at_[hidden]> writes:
>
>> The arrangement is basically based on trust while I control and sort-of

>> police Spirit's core. This arrangement might not be acceptable to boost

>> once Spirit is checked in its CVS. What might be a nice strategy is to
>> continue with the current Spirit-CVS as a sandbox where ideas and
>> prototypes are developed while more stable snapshots are sent of to
>> Boost's CVS.
>>
>> Thoughts?
>
>I worry a little about this arrangement. I don't want to slow down
>Spirit development, but it seems likely that fixes will sometimes want
>to be committed to the Boost CVS by Boost developers (say, when a
>backwards-incompatible change in another library breaks some part of
>Spirit). Maybe we should just give all of your core developers CVS
>access to Boost...?

While I understand Dave's concern above, I also think we should be
flexible.

If we followed the strategy Joel outlines above, it is always possible for
a Boost developer to commit a fix directly to the stable Spirit version in
the Boost CVS.

I would be willing try Joel's strategy. More than that, really, I think it
might be quite useful for a very active library with lots of developers.

What I would like from Joel and the other Spirit CVS participants is
assurance that a procedure is worked out so that we can be sure the two
CVS's are brought into sync at appropriate times.

What would be particularly nice is if the sync is entirely scripted, so
anyone with Boost CVS write access can run it. (Presumably read-only access
to the Spirit CVS is all that is required on that end.) If the entire
Spirit CVS (or entire sub-trees) is to be mirrored in the Boost CVS,
perhaps all that is needed is to have a working directory which is first
updated from the Spirit CVS, and then committed to the Boost CVS. Is that
all there is to a sync operation?

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk