From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-31 01:17:54
"David Abrahams" <dave_at_[hidden]> wrote in message
> on Wed May 30 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
>> Rene Rivera wrote:
>>> Ping... Any comments on this? It would be nice if people voice some
>>> comments on this subject now. Instead of later when we would have to
>>> move a bunch of directories around.
>> Yes, this looks reasonable to me.
>>> stable (full boost tree here)
>>> devel (full boost tree here)
>>> my_branch (full boost tree here)
>>> cmake_a (full boost tree here)
>>> cmake_b (full boost tree here)
>>> boost_1_33_1 (full boost tree here)
>>> boost_1_34_0 (full boost tree here)
>>> xml (partial boost tree here)
>>> explore (partial boost tree here)
>>> xml_b0 (partial boost tree here)
>>> explore_b0 (partial boost tree here)
>>> xml_for_review (partial boost tree here)
>>> explore_for_review (partial boost tree here)
>> I'm still not convinced that the branching in the sandbox
>> should happen outside the projects (as opposed to let each
>> sandbox project organize its own substructure), but I don't
>> have a strong opinion there.
> I agree with Stefan. And that goes for the non-sandbox areas too.
> What is the point of pushing **library-specific** branches and tags up
> to the top level?
As you can imagine I would very much prefer to have independent per project
tree. Something along these lines:
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
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
(this tree will only include accepted libraries)
config-> external reference to config/trunk
python->external reference to python/trunk
and so on.
This should allow existing make system work as expected.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk