Gennadiy Rozental wrote:
As you can imagine I would very much prefer to have independent per project tree. Something along these lines:
python/ trunk/ branches/ releases/ tags/ config trunk/ branches/ releases/ tags/ core trunk/ branches/ releases/ tags/
and so on.
I don't see why svn structure should reflect the one we use for delivery. I also don't see why we need notion of sandbox in this scenario. Every library gets it's own tree and may or may not be part of accepted boost libraries set.
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.
The only question is how to build using this structure. We either need to make changes along the lines I pitched before or create reflection tree using externals: (this tree will only include accepted libraries)
boost config-> external reference to config/trunk python->external reference to python/trunk
and so on.
This should allow existing make system work as expected.
Externals, as currently implemented in SVN, and as the Boost svn server is set up, do *not* work in the general case. If we want to do that we either have to redo/adjust the server set up, or wait until SVN implements the "internals" feature. So yes, any changes that break up the Boost tree would require considerable changes to the building and testing infrastructure. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo