At 08:14 AM 12/11/2002, David Abrahams wrote:
>"Joel de Guzman" <[EMAIL PROTECTED]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- [boost] Sprit into the boost distribution Daniel Yerushalmi
- [boost] Re: Sprit into the boost distribution Carl Daniel
- Re: [boost] Re: Sprit into the boost distributi... Joel de Guzman
- [boost] Re: Re: Sprit into the boost distri... Daniel Yerushalmi
- Re: [boost] Re: Sprit into the boost distri... David Abrahams
- RE: [boost] Re: Sprit into the boost di... Hartmut Kaiser
- Re: [boost] Re: Sprit into the boo... David Abrahams
- Re: [boost] Re: Sprit into the boost di... Beman Dawes
- Re: [boost] Re: Sprit into the boo... Joel de Guzman
- Re: [boost] Re: Sprit into the... David Abrahams
- Re: [boost] Re: Sprit into... Beman Dawes
- Re: [boost] Re: Sprit into... Joel de Guzman
- Re: [boost] Re: Sprit into... Peter Simons
- Re: [boost] Re: Sprit into... Joel de Guzman
- Re: [boost] Re: Sprit into... Peter Simons
- Re: [boost] Re: Sprit into... David Abrahams
- Re: [boost] Re: Sprit into... Anthony Williams