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