On Thu, May 24, 2007 at 10:39:33AM -0500, Rene Rivera wrote:
Yes, that's the structure for the sandbox <http://svn.boost.org/trac/boost/wiki/BoostSandbox>.
Whoops. Sorry about mussin' the dirs. Apologies for not having seen that page before. So where should that stuff go? I'm accustomed to having "sandbox" identify a free-form area. 'sandbox-branches' isn't appropriate either. I think the current sandbox should actually be a subdirectory of sandbox called "projects". Here's another thing. The layout of the sandbox currently does not support independent versioning of projects, e.g., the author of library A has no way to create a branch/tag of A independently of library B. You have to branch the entire sandbox. So you can envision a structure: projects/ a/ trunk/ branches/ somebranch/ otherbranch/ tags/ somerelease/ otherrelease/ b/ trunk/ branches/ somebranch/ otherbranch/ tags/ somerelease/ otherrelease/ (...) Where each of the trunk, branches/*/, tags/*/, dirs contain the standard tree boost/ a/ libs/ a/ src/ docs/ test/ This enables one to create a directory (in the free-form type sandbox, wherever that turns out to be) of the sandbox projects you're watching: % svn pg svn:externals . a https://svn.boost.org/svn/boost/projects/a/trunk b https://svn.boost.org/svn/boost/projects/b/trunk c https://svn.boost.org/svn/boost/projects/c/trunk d https://svn.boost.org/svn/boost/projects/d/tags/stable-release Which shows svn:externals in a new light. The use case "I use svn update to see if there is anything new in the sandbox" works. It also opens up clean ways to support a all kinds of other use-cases, like "i want to restrict commit access to certain branches of various projects because it is release time and I am the release manager". and "I want to create a distribution of boost containing only certain components at certain revisions". But that's another story. Anyhow let me know what you think about moving sandbox => sandbox/(something). -t