On Thu, May 31, 2007 at 02:33:29AM -0400, Gennadiy Rozental wrote:
"Rene Rivera" <grafikrobot@gmail.com> wrote in message news:465E6021.7060407@gmail.com...
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 again?
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. -t