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

From: troy d. straszheim (troy_at_[hidden])
Date: 2007-05-30 19:21:51

On Wed, May 30, 2007 at 04:59:12PM -0400, Doug Gregor wrote:
> Thanks for pointing this out, Rene.
> 
> >     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)
> 
> I don't like having everything live under "boost", because users will  
> then just "svn co https://svn.boost.org/svn/boost/boost" and wonder  
> why they just downloaded 10GB. Not good. Instead, I prefer
> 
> [boost-svn]
>    stable
>    devel
>    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)
> 

There's always the risk that somebody will blindly check out the
entire get everything.  I'm almost certain there is a way (via svn
hook scripts) to prevent anonymous users from doing this in a way that
does not disturb others.

The current mapping of the URL to the repository doesn't make much
sense to me. I'd prefer the base of the repo to be

  http://svn.boost.org/svn

and in the root of the repository a directory 'boost'.  I'm sure this
is a simple tweak of <Location> in an apache .conf file.  If
https://svn.boost.org/svn did map to the root of the repository,
(rather than to a redirect as it does currently) the repo could
contain

   boost/
     stable/
     devel/
     branches/
       (etc)
   sandbox/
     devel
       etc
     branches
       etc
     tags

and the desired 

  http://svn.boost.org/svn/boost/(stable|devel) 

works, and your repository root is also left open, for instance for
infrastructure (like autobuild stuff or the latest-greatest quickbook
setup) that needs to be in source control but doesn't belong in the
distribution since it is distributed on a different time scale.

Personally I prefer

  boost/
    trunk/
    releases/
      v1.33.1/
      v1.34.0/
    branches/
      etc/
      and_so_on/

I omit 'tags' since I don't personally end up with 'tags' that arent
releases.  Something is either a frozen release, or a branch.  We use
per-directory access-control to enforce that releases aren't modified
by anyone other than release managers.

> >     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)
> 
> Same complaint with the sandbox: I'd prefer that we put the latest  
> and greatest into "sandbox", and have separate branches/tags, e.g.,
>
> [boost-svn]
>    sandbox
>      xml
>      explore
>    sandbox-branches
>      xml_b0
>      explore_b0
>    sandbox-tags
>      xml_for_review
>      explore_for_review

But in this structure the branch names of all sandbox library authors
are incident on all other authors.  The number of entries in
sandbox-branches will quickly get out of hand.  Authors also must be
careful about how they name their branches, and have nowhere to put
things that, as with the quickbook/autobuild stuff, might need to be
in source control but aren't part of the distribution.  It is also
very kludgy to provide per-project access controls when the contents
of one logical project is spread across the repository in this way.

In this structure:

  sandbox
    xml
      trunk
      branches
        abortive_attempt
        will_be_useful_later
        dont_remember_what_i_was_doing
      releases
        v0.0.666
    explore
      trunk
      branches
  for_review // this sounds convenient
    xml      // copy of sandbox/xml/trunk
    explore

It isnt necessary in the normal course of business to look past the
branch names of others; one can augment the trunk/branches/releases
scheme if necessary for associated stuff without disturbing others,
and it is easy to provide per-project access controls.

-t