From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2007-06-01 01:29:53
On Wednesday 30 May 2007 22:29:05 Rene Rivera wrote:
> stable (full boost tree here)
> devel (full boost tree here)
> my_branch (full boost tree here)
> cmake_a (full boost tree here)
> cmake_b (full boost tree here)
> 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,
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?
> xml (partial boost tree here)
> explore (partial boost tree here)
> xml_b0 (partial boost tree here)
> explore_b0 (partial boost tree here)
> 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).
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk