[Subversion switch] Abandoned sandbox directories/projects?
Hello all, As a prelude to the conversion from CVS to Subversion, I am auditing the top-level directories inside the Boost Sandbox CVS. My plan is to perform some cleanup of the CVS repository structure before moving it to Subversion, so that the resulting Subversion repository will have a clean structure. These are the top-level directories in the Sandbox CVS, and what I intend to do with each: - boost: This directory contains a two useless bits. There is a DocBook DTD I committed a long time ago, and a small part of "sequence_algo". The latter has been completely moved into "boost- sandbox" already, where there is more history. I will remove this directory. - boost-sandbox: This is where most development goes on. This directory will live on to become "the sandbox" in the Boost Subversion repository. - database: This appears to be some work toward a database library. I plan to move its contents into boost-sandbox/libs/database. - libs: This contains more sequence_algo bits that have already been cloned (and further developed) in boost-sandbox. I will remove this directory. - website: This top-level directory is empty, and will be removed. - xpressive: This looks like an early version of xpressive, although recent development on this library happened in "boost- sandbox", and of course the library itself is now part of Boost. I plan to remove this directory; we can always go back to the CVS repository tarball if we find we *really* need it, but that's quite unlikely. If you have any objections to these changes, scream loudly and very soon :) Cheers, Doug
Quoting Doug Gregor:
- boost-sandbox: This is where most development goes on. This directory will live on to become "the sandbox" in the Boost Subversion repository.
I'm not sure how to interpret the quotes here. Does that mean that the sandbox directory will have a whitespace character in its name? (It does not sound like a good idea to me; "sandbox" would do just fine.) Best regards, Guillaume
On Apr 2, 2007, at 10:55 AM, Guillaume Melquiond wrote:
Quoting Doug Gregor:
- boost-sandbox: This is where most development goes on. This directory will live on to become "the sandbox" in the Boost Subversion repository.
I'm not sure how to interpret the quotes here. Does that mean that the sandbox directory will have a whitespace character in its name? (It does not sound like a good idea to me; "sandbox" would do just fine.)
Sorry, I was ambiguous. Inside the Boost Subversion repository, "sandbox" will be the name of the Boost sandbox, and will contain all of the files currently in the boost-sandbox directory of the Sandbox CVS repository (plus the changes I noted above). Cheers, Doug
Doug Gregor wrote:
These are the top-level directories in the Sandbox CVS, and what I intend to do with each:
<snip>
- xpressive: This looks like an early version of xpressive, although recent development on this library happened in "boost- sandbox", and of course the library itself is now part of Boost. I plan to remove this directory; we can always go back to the CVS repository tarball if we find we *really* need it, but that's quite unlikely.
Nuke it. It was a mistake. Feel free to remove boost/xpressive and libs/xpressive from boost-sandbox as well. I would if I could. Thanks for taking care of this! -- Eric Niebler Boost Consulting www.boost-consulting.com
Doug Gregor wrote:
- boost-sandbox: This is where most development goes on. This directory will live on to become "the sandbox" in the Boost Subversion repository.
- database: This appears to be some work toward a database library. I plan to move its contents into boost-sandbox/libs/database.
Wouldn't it be a good idea to mandate a particular layout for sandbox projects ? I have added an 'xml' directory / project to the toplevel boost-sandbox directory, but I also see other projects spread across boost-sandbox/boost/, boost-sandbox/libs/, etc., i.e. without a single entry point. I believe the single-entry-point layout is advantageous for a number of reasons. But I don't have a very strong opinion, as long as things are consistent. :-) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Apr 2, 2007, at 11:57 AM, Stefan Seefeld wrote:
Doug Gregor wrote:
- boost-sandbox: This is where most development goes on. This directory will live on to become "the sandbox" in the Boost Subversion repository.
- database: This appears to be some work toward a database library. I plan to move its contents into boost-sandbox/libs/ database.
Wouldn't it be a good idea to mandate a particular layout for sandbox projects ? I have added an 'xml' directory / project to the toplevel boost-sandbox directory, but I also see other projects spread across boost-sandbox/boost/, boost-sandbox/libs/, etc., i.e. without a single entry point.
I assumed that the sandbox structure should mirror that of the standard Boost repository.
I believe the single-entry-point layout is advantageous for a number of reasons. But I don't have a very strong opinion, as long as things are consistent. :-)
Yes, it probably would be advantageous to have a single-entry-point layout, but we haven't found a good way to do it. svn:externals was one potential approach, but they aren't quite powerful enough to do what we need. For now, I suggest we keep the sandbox organization as-is, and consistent with the main Boost repository. They'll both end up living in the same Subversion repository in the end, which should simplify things considerably. Cheers, Doug
Doug Gregor wrote:
Yes, it probably would be advantageous to have a single-entry-point layout, but we haven't found a good way to do it. svn:externals was one potential approach, but they aren't quite powerful enough to do what we need.
svn:externals would be useful to make sandbox projects appear as full boost versions (plus the new bits) to the user. Why not simply treat the two (main boost, and sandbox) as separate ? All it should take to build something against the two is an additional set of paths (-I and -L), which should be easily hackable into the build system. The same strategy would be useful to build individual boost libraries in stand-alone mode, i.e. against all dependencies pre-installed. (See the discussion on boost modularity.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Doug Gregor wrote:
Yes, it probably would be advantageous to have a single-entry-point layout, but we haven't found a good way to do it. svn:externals was one potential approach, but they aren't quite powerful enough to do what we need.
svn:externals would be useful to make sandbox projects appear as full boost versions (plus the new bits) to the user. Why not simply treat the two (main boost, and sandbox) as separate ? All it should take to build something against the two is an additional set of paths (-I and -L), which should be easily hackable into the build system.
The same strategy would be useful to build individual boost libraries in stand-alone mode, i.e. against all dependencies pre-installed. (See the discussion on boost modularity.)
Please also see this previous discussion <http://thread.gmane.org/gmane.comp.lib.boost.devel/113512> -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Apr 2, 2007, at 12:30 PM, Rene Rivera wrote:
Please also see this previous discussion <http://thread.gmane.org/gmane.comp.lib.boost.devel/113512>
We can very, very easily move to this structure after we've moved to Subversion. Moving files and directories in Subversion is cheap, so doing it beforehand isn't going to help much. Plus, I'm not sure I could put all of the bits and pieces of the sandbox into the right places as part of the CVS->SVN conversion: there are a LOT of things in the sandbox that I know nothing about. We can decide on whether we want this new structure for the sandbox (it's fine by me), and people can start moving/deleting their parts of the sandbox as soon as its in Subversion. Cheers, Doug
Doug Gregor wrote:
On Apr 2, 2007, at 12:30 PM, Rene Rivera wrote:
Please also see this previous discussion <http://thread.gmane.org/gmane.comp.lib.boost.devel/113512>
We can very, very easily move to this structure after we've moved to Subversion. Moving files and directories in Subversion is cheap, so doing it beforehand isn't going to help much. Plus, I'm not sure I could put all of the bits and pieces of the sandbox into the right places as part of the CVS->SVN conversion: there are a LOT of things in the sandbox that I know nothing about.
We can decide on whether we want this new structure for the sandbox (it's fine by me), and people can start moving/deleting their parts of the sandbox as soon as its in Subversion.
Sounds fine. I certainly didn't mean to imply to do all the re-layout work as part of the initial conversion process. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Mon Apr 02 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Doug Gregor wrote:
On Apr 2, 2007, at 12:30 PM, Rene Rivera wrote:
Please also see this previous discussion <http://thread.gmane.org/gmane.comp.lib.boost.devel/113512>
We can very, very easily move to this structure after we've moved to Subversion. Moving files and directories in Subversion is cheap, so doing it beforehand isn't going to help much. Plus, I'm not sure I could put all of the bits and pieces of the sandbox into the right places as part of the CVS->SVN conversion: there are a LOT of things in the sandbox that I know nothing about.
We can decide on whether we want this new structure for the sandbox (it's fine by me), and people can start moving/deleting their parts of the sandbox as soon as its in Subversion.
Sounds fine. I certainly didn't mean to imply to do all the re-layout work as part of the initial conversion process.
Yeah, why do any of it before converting? -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On Apr 4, 2007, at 6:48 PM, David Abrahams wrote:
on Mon Apr 02 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote:
Doug Gregor wrote:
We can decide on whether we want this new structure for the sandbox (it's fine by me), and people can start moving/deleting their parts of the sandbox as soon as its in Subversion.
Sounds fine. I certainly didn't mean to imply to do all the re- layout work as part of the initial conversion process.
Yeah, why do any of it before converting?
No reason to. Anyway, it looks like everyone is in favor of a project- centric layout for the Sandbox. Is the "Sandbox Organization" section at the bottom of the following page clear enough for everyone? http://svn.boost.org/trac/boost/wiki/BoostSubversion Cheers, Doug
Doug Gregor wrote:
No reason to. Anyway, it looks like everyone is in favor of a project- centric layout for the Sandbox. Is the "Sandbox Organization" section at the bottom of the following page clear enough for everyone?
That looks good, thanks ! In addition, it may be good to add common infrastructure one level above to make it easy to set up a proper build system. (My (not sy hypothetical ;-) ) xml project for example still uses Makefiles, and I have no idea yet how to migrate to boost.build.) May be this would be a good place to use svn:externals for, i.e. set up a build system similar to the one in trunk, and let users refer to it from their own projects via svn:externals ? With that, whenever I check out boost-sandbox/xml, I get a fully self-contained working copy, without having to maintain the common (infrastructure) bits myself. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Apr 2, 2007, at 12:22 PM, Stefan Seefeld wrote:
Doug Gregor wrote:
Yes, it probably would be advantageous to have a single-entry-point layout, but we haven't found a good way to do it. svn:externals was one potential approach, but they aren't quite powerful enough to do what we need.
svn:externals would be useful to make sandbox projects appear as full boost versions (plus the new bits) to the user.
Except that you can only use svn:externals for *directories*, not for individual files. So, for example, while I could use svn:externals to bring in directories like "boost/mpi" and "libs/mpi", I could not use them to bring in "boost/mpi/mpi.hpp". I've looked into svn:externals; either I missed something big, or they just aren't sufficient to do what we want.
Why not simply treat the two (main boost, and sandbox) as separate ? All it should take to build something against the two is an additional set of paths (-I and -L), which should be easily hackable into the build system.
We are treating them as separate, but mirroring the layout.
The same strategy would be useful to build individual boost libraries in stand-alone mode, i.e. against all dependencies pre-installed. (See the discussion on boost modularity.)
Only if it's a strategy that works. svn:externals don't do that. Do we have something else? Cheers, Doug
Doug Gregor wrote:
Why not simply treat the two (main boost, and sandbox) as separate ? All it should take to build something against the two is an additional set of paths (-I and -L), which should be easily hackable into the build system.
We are treating them as separate, but mirroring the layout.
I'm confused. They aren't separate, physically, as they don't (currently) have all their own entry point. Making them separate is what I'm proposing.
The same strategy would be useful to build individual boost libraries in stand-alone mode, i.e. against all dependencies pre-installed. (See the discussion on boost modularity.)
Only if it's a strategy that works. svn:externals don't do that. Do we have something else?
Sorry for the confusion. I'm not promoting svn:externals. I'm proposing to use projects in separate subdirectories, and just using multiple search paths (-I and -L) to drag in the right versions. It seems that's exactly what has been discussed as far back as November 2004 (thanks Rene for the link !). Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, Apr 02, 2007 at 01:07:36PM -0400, Doug Gregor <dgregor@cs.indiana.edu> wrote:
On Apr 2, 2007, at 12:22 PM, Stefan Seefeld wrote:
Doug Gregor wrote:
Yes, it probably would be advantageous to have a single-entry-point layout, but we haven't found a good way to do it. svn:externals was one potential approach, but they aren't quite powerful enough to do what we need.
svn:externals would be useful to make sandbox projects appear as full boost versions (plus the new bits) to the user.
Except that you can only use svn:externals for *directories*, not for individual files. So, for example, while I could use svn:externals to bring in directories like "boost/mpi" and "libs/mpi", I could not use them to bring in "boost/mpi/mpi.hpp". I've looked into svn:externals; either I missed something big, or they just aren't sufficient to do what we want.
This and because one could not have versioned links that point onto a specific version. I think in the boost-sandbox case this isnt that much of an issue, but for our needs that was too limiting. Because of that we were looking at http://venge.net/monotone There branches are simply a kind of membership and not a copied directory. Due to its distributed nature, it allows users to work on their own sandbox branch, and share that with other users or the whole community. So if someone wants to start working on a new library for boost, the developer simply get a current working copy and start adding the code. When ready for the first commit he simply uses a differen branch name. When done the developer can sync with the main server of boost and provide the branch name to other boost developers. If the library is submitted and accepted to boost, the integrator simply has to annotate the versions the developer provided, with the official boost branch certificate. Here are some nice aspects of monotone: http://venge.net/mtn-wiki/BranchAnalogy http://venge.net/mtn-wiki/DaggyFixes http://venge.net/mtn-wiki/UsingCerts I am sorry for throwing that into the discussion, after you already picked subversion. Regards Andreas Pokorny
On Mon, 2007-04-09 at 10:01 +0200, Andreas Pokorny wrote:
On Mon, Apr 02, 2007 at 01:07:36PM -0400, Doug Gregor <dgregor@cs.indiana.edu> wrote:
Except that you can only use svn:externals for *directories*, not for individual files. So, for example, while I could use svn:externals to bring in directories like "boost/mpi" and "libs/mpi", I could not use them to bring in "boost/mpi/mpi.hpp". I've looked into svn:externals; either I missed something big, or they just aren't sufficient to do what we want.
This and because one could not have versioned links that point onto a specific version. I think in the boost-sandbox case this isnt that much of an issue, but for our needs that was too limiting.
Right.
Because of that we were looking at http://venge.net/monotone
We are not considering any other version control system. Cheers, Doug
Andreas Pokorny wrote:
On Mon, Apr 02, 2007 at 01:07:36PM -0400, Doug Gregor <dgregor@cs.indiana.edu> wrote:
On Apr 2, 2007, at 12:22 PM, Stefan Seefeld wrote:
Except that you can only use svn:externals for *directories*, not for individual files. So, for example, while I could use svn:externals to bring in directories like "boost/mpi" and "libs/mpi", I could not use them to bring in "boost/mpi/mpi.hpp". I've looked into svn:externals; either I missed something big, or they just aren't sufficient to do what we want.
This and because one could not have versioned links that point onto a specific version. I think in the boost-sandbox case this isnt that much of an issue, but for our needs that was too limiting.
Please note, that kind of links are supported: (from http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html) $ svn propget svn:externals calc third-party/sounds http://sounds.red-bean.com/repos third-party/skins http://skins.red-bean.com/repositories/skinproj third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker (look at the '-r21' in the last line) Greetings Adrián
on Mon Apr 02 2007, Doug Gregor <dgregor-AT-cs.indiana.edu> wrote:
On Apr 2, 2007, at 11:57 AM, Stefan Seefeld wrote:
Doug Gregor wrote:
- boost-sandbox: This is where most development goes on. This directory will live on to become "the sandbox" in the Boost Subversion repository.
- database: This appears to be some work toward a database library. I plan to move its contents into boost-sandbox/libs/ database.
Wouldn't it be a good idea to mandate a particular layout for sandbox projects ? I have added an 'xml' directory / project to the toplevel boost-sandbox directory, but I also see other projects spread across boost-sandbox/boost/, boost-sandbox/libs/, etc., i.e. without a single entry point.
I assumed that the sandbox structure should mirror that of the standard Boost repository.
That makes it very hard to use one sandbox project without accepting whatever headers are in all the others. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
participants (9)
-
Adrián Etchevarne -
Andreas Pokorny -
David Abrahams -
Doug Gregor -
Douglas Gregor -
Eric Niebler -
Guillaume Melquiond -
Rene Rivera -
Stefan Seefeld