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

From: troy d. straszheim (troy_at_[hidden])
Date: 2007-05-31 10:28:10

On Thu, May 31, 2007 at 02:33:29AM -0400, Gennadiy Rozental wrote:
> 
> "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.
> 
> > 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