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. If I'm right then, while I understand Peter's concerns, I see no other way to proceed; removing unstable stuff from HEAD sounds much more painful, if feasible at all. Given how long development on HEAD has gone forward with respect to 1.34 I wonder if it wouldn't be a good idea to try and put together a schedule for the merge of currently stable libraries, so as to ensure each lot doesn't indeed cause any regression before the next one goes in. We could start with the libraries that are already present in 1.34 and then move on to the newer ones. A tightly controlled approach might result in shorter delays, while avoiding Jeff's stricter approach of leaving out of 1.35 any evolution of existing libraries. Cheers, Nicola Musatti