Re: [boost] SVN repo structure... [was: Subversion structure in KDE]

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-31 01:17:54

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:87odk1d2p8.fsf_at_grogan.peloton...
>
> 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.
>>
>>> [boost-svn]
>>>     boost
>>>       stable (full boost tree here)
>>>       devel (full boost tree here)
>>>       branches
>>>         my_branch (full boost tree here)
>>>         cmake_a (full boost tree here)
>>>         cmake_b (full boost tree here)
>>>       tags
>>>         boost_1_33_1 (full boost tree here)
>>>         boost_1_34_0 (full boost tree here)
>>>     sandbox
>>>       devel
>>>         xml (partial boost tree here)
>>>         explore  (partial boost tree here)
>>>       branches
>>>         xml_b0 (partial boost tree here)
>>>         explore_b0  (partial boost tree here)
>>>       tags
>>>         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:

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.

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.

Gennadiy