On May 2, 2007, at 9:55 AM, Nicola Musatti wrote:
Doug Gregor <dgregor <at> osl.iu.edu> writes: [...]
I know. I, too, have a bunch of stable code on HEAD that is going to be a pain to move over. To help ease this transition, I'll come up with the appropriate "svn merge" commands to make it easy to pull changes from HEAD into the development branch. Then, it should be only a small matter to test them locally and commit them to the development branch. If someone does cause problems with such a commit, Subversion makes it very, very ease to revert those changes... and we will.
Excuse me, but aren't we supposed to be moving towards Beman's new process? If that's the case, I'm not sure I understand the way you're naming the future subversion branches. The way I see it the current CVS HEAD will become svn development, i.e. the place where things are allowed to break for short periods; 1.34 on the other hand is going to become the starting point for the svn stable branch, where commits are immediately backed out if they cause regressions.
*Sigh*. This is why it's better to look at concrete proposals than to discuss without them... we all assume different things about the unsaid details. When we release 1.34.0, we switch to Subversion. The repository layout (documented at http://svn.boost.org/trac/boost/wiki/ BoostSubversion) contains two branches, "stable" and "devel". Changes go into devel first, get tested, then migrate to the "release-ready" stable branch. IIRC, this is one of the recommendations in Beman's proposal, and it's much easier to enforce in the world of Subversion. When we switch to Subversion, the 1.34.0 release branch becomes both "stable" and "devel", giving us a clean slate. The current CVS HEAD becomes a branch (branches/post-1.34-head). Developers can migrate changes from post-1.34-head to "devel", where they will be tested, fixed, and eventually moved to "stable" for a release. - Doug