From: troy d. straszheim (troy_at_[hidden])
Date: 2007-05-31 10:28:10
On Thu, May 31, 2007 at 02:33:29AM -0400, Gennadiy Rozental wrote:
> "Rene Rivera" <grafikrobot_at_[hidden]> wrote in message
> > Currently the reasons not to do it that way are that it's not the way
> > Boost has worked politically.
> > And I really don't want to get into such a
> > debate on this thread. If you want to raise the idea of library
> > modularity, again, I would suggest another thread. I'm just trying to
> > drive people into considering what SVN arrangement accommodates our
> > current and historical uses.
> My idea of "library modularity" or rather independent library releases is
> kinda orthogonal. Though obviosly related. It's more has to do with what we
> put in <lib>/releases and how we deploy boost as a whole. The above svn
> structure is more natural for my approach - that's true. But it has the
> value of it's own even with existing build/deployment practice, don't you
> agree? Among other things it gives nice logical and phisical separation of
> all the libs with their private branches. And we donlt have to duplicate
> tree structure for accepted/proposed libs.
There are very compelling reasons to do it this way (branches as
subdirs of projects) that do *NOT* involve splitting up the boost C++
libraries themselves (the hot issue that I'm trying to avoid). It:
* doesn't inflict the universe of branch names on each developer
* allows per-project access control in the repository (access control,
not versioning, like restricting commits to release branches)
* allows for versioning associated code/resources (e.g. autobuild
scripts/infrastructure, fop/docboock stuff that goes with
quickbook), that must be in version control and will need to be
easily updated by users on a timescale that doesn't match overall
releases of boost.
> > Externals, as currently implemented in SVN, and as the Boost svn server
> > is set up, do *not* work in the general case.
> I've seen some post in this regard. Could you clarify what the problem is
Let's take the externals stuff to another thread.
> > If we want to do that we
> > either have to redo/adjust the server set up,
> How difficult is this?
> > or wait until SVN
> > implements the "internals" feature.
> What is "internals" and when can we expect it to be implemented?
> > So yes, any changes that break up the Boost tree would require
> > considerable changes to the building and testing infrastructure.
> I hoped we could split the difference. Move to better (IMO obviosly),
> independent code structure while keep using existing infrastructure.
> Eventually we can employ all the power of independent component development.
I think I agree with you, but there's lots to be debated first and no
compellng reason to do this now... In any case such a transformation
would happen piecemeal after a basic import into svn.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk