2009/2/24 Rene Rivera <grafikrobot@gmail.com>:
Why do you want the change?
The main reason reason is that we're currently using the sandbox directory in two different ways and it's a mess. If you want to check out the boost, libs, etc. stuff then it gets mixed up with the individual library directories, the history gets is totally confused. Sometime the libraries in their own directory end up using the shared boost build files and sometimes they don't. It's hard to get an idea of what's available when looking in the repository.
on Wed Feb 18 2009, Daniel James <daniel_james-AT-fmail.co.uk> wrote:
/svn/boost/projects/chrono/trunk /svn/boost/projects/chrono/branches /svn/boost/projects/move_semantics/trunk /svn/boost/projects/move_semantics/branches
2009/2/24 Rene Rivera <grafikrobot@gmail.com>:
After all the above is no different than:
/svn/boost/sandbox/chrono /svn/boost/sandbox-branches/chrono /svn/boost/sandbox/move_semantics /svn/boost/sandbox-branches/move_semantics
No, it's different. Using the standard layout is more understandable - both to humans and software. For example, both bzr and git's subversion integration work better if the directories are in the standard layout. If you look in the sandbox-branches and sandbox-tags, it's obvious that no one is sure how to use them. Many of the names give little clues to what they contain. Libraries follow inconsistent conventions which make it more difficult to remember urls, or find the branch that you're looking for. Since branches and tags are separated from the trunk it's easy to miss that they exist. Also, the layout you've described doesn't allow for multiple branches and tags - do you use a second level, or do you use multiple names at the same level? Again, people end up adopting different conventions. But having said all of that, the downside to change is the disruption it would cause - and that could easily outweigh the advantages. Especially if there's little support for the change. Daniel