Re: [boost] Changing the arrangement of files within our SCM

From: Daryle Walker (darylew_at_[hidden])
Date: 2006-07-23 11:57:46

On 7/22/06 8:01 PM, "David Abrahams" <dave_at_[hidden]> wrote:

> Daryle Walker <darylew_at_[hidden]> writes:
> 
>> For users, we create a final archive by copying the _contents_ of each
>> top-level directory, recursively merging the contents of repeated child
>> directories.  From their perspective, nothing has changed.
>> 
>> Building changes radically for developers _of_ Boost code, though.
> 
> Wouldn't that mean developers _of_ Boost code would be working with a
> different system of include paths than users?  Seems like it coudl
> lead to hard-to-find bugs?

The compiler/IDE searches for file paths among the union of its list of
directories.  The partitioning of the files among the search directories
shouldn't matter as long as each file's relative path is distinct.  Each
file in the current archive will move to exactly one of the new library
directories.  There shouldn't be any duplication.

This plan will work better with Subversion, since that SCM system records
file _and_ directory moves.  This allows us to move one library/tool at a
time, leaving the rest in the "General" directory.

>> I think this arrangement would synergize with the Release Overview proposal
>> at <http://mysite.verizon.net/beman/release_overview.html>.  Both proposals
>> are supposed to help with the scaling-up of Boost.
> 
> How?

Beman wants us to move from monolithic releases to releasing whenever a
library gets a finalized update (or a few updates are built up).  He also
wants to allow libraries to be updated asynchronously.  Separating eases
counting, or otherwise iterating, over each library (like regressions, other
testing, making an automatic "libraries.html").  It's also easier to add a
new library, if the author makes his/her archive mirror the final
(user-level) directories, because our scripts will handle the merges.  You
could easily remove a retired library.  It will be easier for an author to
get the minimum number of files needed to change a library.  You would do it
by just checking out the specific library directory.  Any missing
dependencies will become obvious in compiling; you can similarly checkout
other library directories to get an exact list of dependencies.

> Any proposal to radically alter the way we do things ought to actually
> explain its benefits and how they will be achieved, and also what
> problem the proposal is solving.

We already treat each library separately in most of the things we discuss on
this list.  Keeping each library separate until release time helps because
authors can manipulate his/her library wholesale without interfering with
files from other libraries (or forgetting a file to mess with).

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com