Re: [boost] Organizing a large project with svn:externals (Was: Boost Development Environment proposal)

From: troy d straszheim (troy_at_[hidden])
Date: 2007-06-17 23:58:39

On Sun, Jun 17, 2007 at 10:01:07AM -0500, Rene Rivera wrote:
> > 
> > This 'inverted' structure has several disadvantages that were
> > discussed.  You wouldn't want to avoid 'private' meta-projects.  They
> > are one of the main features of the system.
> 
> Could you point out what those disadvantages are? AFAIK a top-level, 
> what you call inverted, is equivalent to a bottom-up arrangement.

The proposed structure facilitates such fundamental operations as:

  * renaming a project (all the branches come with you)
  * deleting a project (same)
  * finding out what branches exist for a project (they're right there)
  * controlling commit access to individual projects (it's only one directory)
  * giving descriptive names to branches (there are separate branch namespaces)

I consider it a disadvantage that the current sandbox layout
significantly hinders/complicates each of these operations.  In the
proposed layout:

** you can easily see what projects exist

   Not true for the current sandbox.  A look at

     http://svn.boost.org/trac/boost/browser/sandbox

   does not reveal that a project called 'outfmt' exists.  It is in
   sandbox-branches, but it isn't obvious there either.  

** you can easily locate all the branches of a project

   Example: looking at 'units' in sandbox/, you can't see that
   steven_watanabe has a branch of 'units' in sandbox-branches that
   might be interesting.  If it were associaated with 'units', I
   could.

   Example 2: you want to find all the branches of 'graph'.  You can't
   find this in the current sandbox, for starters because 'graph'
   isn't there at all.  There's code for it in the branches area, but
   it is hidden in 'expaler'.

** you can easily rename/delete a project and all of its branches.

   Not easy to do with the current layout.

   Example: When 'outfmt' becomes 'oformat', you can't easily find the
   branches to rename them all.  In the proposed layout, this Just
   Happens.

   Example 2: When you delete 'units' from the sandbox you probably
   won't catch steven_watanabe's branch, since it is called
   'steven_watanabe' and not 'units'.

** you have more namespace for your own pet branch, so you can give
   your branches more succint and descriptive names.

   This is because the branch namespace (directory) is private to the
   project.

   In the current layout the branch names of all projects are
   commingled.  When branching my project I must be aware of what
   branchnames are already taken by other projects.  So you have to
   adopt arbitrary naming schemes... a mess.

-t