Boost logo

Boost :

Subject: Re: [boost] Sandbox structure in subversion (was Re: [move] Library uploaded to sandbox)
From: Daniel James (daniel_james_at_[hidden])
Date: 2009-02-27 06:14:40


2009/2/24 Rene Rivera <grafikrobot_at_[hidden]>:
>
> 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_at_[hidden]>:
>
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk