On Wednesday 30 May 2007 22:29:05 Rene Rivera wrote:
[boost-svn] 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)
boost/stable would contain a copy of boost/tags/boost_1_34_0 currently and both would be equal to what you get when you download the tarballs/zips, right? Further, if I want to finally finish the port to Windows CE, admins could create a branch and assign commit-rights to me (I don't have them otherwise) so I don't have to use my company's private repository and so that everybody can see and contribute. When the code has been thoroughly tested, the changes can be merged into boost/devel. Is that one of the goals?
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)
I wonder what we need the sandbox for? I would say that it's for separated development of features. However, for that I could as well use a branch like above that includes a complete Boost tree. This wasn't the case for CVS, where copying files around had significant overhead IIRC, but with Subversion you get cheap copies. Now, if someone wants to test then new lib, they simply 'svn switch' their working copy from boost/devel to boost/branches/some-new-lib and run their buildscripts. IOW, having a complete tree will reduce the barrier to testing it (theoretically, the only changes are that one library and all other code will remain unaffected) and will also reveal when library experimenters fail to regularly merge changes from boost/devel to their tree, which in the other direction affects the ability to merge their new library to boost/devel. Of course, this requires some discipline: People need to know which version their branch is based on. Further, they need to know which of the possible changes to their base have been merged. The first can rather easily be determined from the logs, but the second requires some manual work because Subversion doesn't yet feature merge tracking (due in version 1.5 or 1.6). Example: I'd do my above port based on 1.34 first, simply because that one is well tested and stable. Later, I would split off a development version and merge the changes between 1.34 and the current version into it, to prepare for the changes to be merged back. Once the changes are merged back, the development branch could be deleted again.
The one drawback I can see is that one common case, of updating boost/stable and boost/devel can't be done in one go.
I don't think that updating boost/stable happens often, but that of course depends on what you want to put there. Can you tell us what you want there? Uli