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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-31 02:33:29

"Rene Rivera" <grafikrobot_at_[hidden]> wrote in message 
news:465E6021.7060407_at_gmail.com...
> Currently the reasons not to do it that way are that it's not the way
> Boost has worked politically.

What politic do you mean? I am usually politically ignorant, so please be 
more specific.

> 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.

>> 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.

I've seen some post in this regard. Could you clarify what the problem is 
again?

> 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.

Gennadiy