Re: [boost] Boost Development Environment proposal

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 13:41:21

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:012301c7a6cc$59a39360$6407a80a_at_pdimov2...
> Gennadiy Rozental wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>> news:010801c7a6c9$b39badb0$6407a80a_at_pdimov2...
>
>>> I'd still like to have a 'trunk' from which I can 'svn update'.
>>
>> 1. Why can't you do it from root?
>> 2. With independent development and svn externals you don't need to
>> do it as frequently. you do update in your local directory and it
>> updates all you depend on.
>
> I'm focused on getting ~85% of the benefits with ~30% of the effort and a
> clear migration path.
>
> My current development model is sync against CVS HEAD, do work, commit,
> check test results, fix. My use model is sync against CVS HEAD, compile
> project, yell at whoever introduced a regression in the boost component 
> I'm
> using. This works well for me and I'd like to keep working in a similar 
> way.

IMO this is not the desirable scheme in general. Actually this is exactly 
what we *should not* be doing IMO. Let's say I am testing some workarounds 
for particular compiler. It might break in some other place. I don't see why 
you need to bother. I may not have time to fix it right away and/or I may 
still to do more testing, try different things.
  What you should be doing instead is point to "released"/stable version of 
my library and do your own developemnt without minding mine. Once you done 
you switch to my latest. If it works you release new version of your 
library. If not, you

* either release version of your library that depends on older version of 
mine.
* or yell at me and
   * either I fix it
   * or I yell at you back and you fix it
   * or we find some other solution

The important point here is that until we find this solution the algorithm 
that select versions for boost umbrella release wont pick any new releases I 
made. This is an incentive for me to make sure my new version works for all 
who depend on me.

> The structure and organization I have in mind is doable incrementally. 
> There
> is one relatively painful step of reorganizing the boost directory
> structure, but it's process-independent. After that, developers can 
> continue
> working against the trunk as they do now. Once the test matrix for a 
> library
> is green, the developer can create a version tag. This can be done
> automatically as you suggest, but it can also be done manually as SVN 
> makes
> it relatively easy.

What directory structure are you talking about?

> The dependency management can also be introduced at a later date. It is 
> not
> as fine grained as in your proposal - you can't depend on a specific
> version - and this is intentional, to keep things simple.

What value does it have then? This is what we got now "informally".

> This step requires
> the test infrastructure to be updated to allow testing a specific library
> and only pull a subtree.

If there is no way to point to older version of my depenencies, what the 
poiont of subtree pulling? They all going to be the same.

> A release also doesn't require any new tools; it can be done manually by 
> the
> release manager. We may be able to streamline it with tools in the future,
> of course.

Release still require all libraries to be tested together, right?

Gennadiy