
On Wed, May 30, 2007 at 04:59:12PM -0400, Doug Gregor wrote:
Thanks for pointing this out, Rene.
boost stable (full boost tree here) devel (full boost tree here) branches my_branch (full boost tree here) cmake_a (full boost tree here) cmake_b (full boost tree here) tags boost_1_33_1 (full boost tree here) boost_1_34_0 (full boost tree here)
I don't like having everything live under "boost", because users will then just "svn co https://svn.boost.org/svn/boost/boost" and wonder why they just downloaded 10GB. Not good. Instead, I prefer
[boost-svn] stable devel branches my_branch (full boost tree here) cmake_a (full boost tree here) cmake_b (full boost tree here) tags boost_1_33_1 (full boost tree here) boost_1_34_0 (full boost tree here)
There's always the risk that somebody will blindly check out the entire get everything. I'm almost certain there is a way (via svn hook scripts) to prevent anonymous users from doing this in a way that does not disturb others. The current mapping of the URL to the repository doesn't make much sense to me. I'd prefer the base of the repo to be http://svn.boost.org/svn and in the root of the repository a directory 'boost'. I'm sure this is a simple tweak of <Location> in an apache .conf file. If https://svn.boost.org/svn did map to the root of the repository, (rather than to a redirect as it does currently) the repo could contain boost/ stable/ devel/ branches/ (etc) sandbox/ devel etc branches etc tags and the desired http://svn.boost.org/svn/boost/(stable|devel) works, and your repository root is also left open, for instance for infrastructure (like autobuild stuff or the latest-greatest quickbook setup) that needs to be in source control but doesn't belong in the distribution since it is distributed on a different time scale. Personally I prefer boost/ trunk/ releases/ v1.33.1/ v1.34.0/ branches/ etc/ and_so_on/ I omit 'tags' since I don't personally end up with 'tags' that arent releases. Something is either a frozen release, or a branch. We use per-directory access-control to enforce that releases aren't modified by anyone other than release managers.
sandbox devel xml (partial boost tree here) explore (partial boost tree here) branches xml_b0 (partial boost tree here) explore_b0 (partial boost tree here) tags xml_for_review (partial boost tree here) explore_for_review (partial boost tree here)
Same complaint with the sandbox: I'd prefer that we put the latest and greatest into "sandbox", and have separate branches/tags, e.g.,
[boost-svn] sandbox xml explore sandbox-branches xml_b0 explore_b0 sandbox-tags xml_for_review explore_for_review
But in this structure the branch names of all sandbox library authors are incident on all other authors. The number of entries in sandbox-branches will quickly get out of hand. Authors also must be careful about how they name their branches, and have nowhere to put things that, as with the quickbook/autobuild stuff, might need to be in source control but aren't part of the distribution. It is also very kludgy to provide per-project access controls when the contents of one logical project is spread across the repository in this way. In this structure: sandbox xml trunk branches abortive_attempt will_be_useful_later dont_remember_what_i_was_doing releases v0.0.666 explore trunk branches for_review // this sounds convenient xml // copy of sandbox/xml/trunk explore It isnt necessary in the normal course of business to look past the branch names of others; one can augment the trunk/branches/releases scheme if necessary for associated stuff without disturbing others, and it is easy to provide per-project access controls. -t