On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote: > On Fri, 9 Mar 2001, Greg Stein wrote: > > > I don't think it has anything to do with mechanics, nor will throwing more > > process at the problem fix it. (more process will simply bog down what we > > can accomplish) > > ...? if nothing else: > > cd apr > cvs tag -b apr_dev [needs recursive option] > > cd .. > mkdir apr_dev; cd !$ > cvs co -r apr_dev apr > > cd .. > > mkdir httpd_combined; cd !$ > cvs co httpd > rm -fr apr > mv ../apr_dev apr > > this assumes that the apr library is in httpd/apr, which it probably > isn't, it's probably in httpd/src. > > the same process applies to if you want to use the version of apr that's > already in httpd, except you do: > > rm -fr httpd/apr > cvs co -r apr_dev httpd/apr > > > > No... the problem is about perception. The rate of change recently has just > > been quite high. It just isn't very conceivable to make a release in that > > environment. > > ... > > ah, that's different. > > _however_ :) once you _get_ to the point where cvs main is > always-releasable, then using this multi-tag process could help make cvs > main _remain_ always-releasable. > > for, as you described - some significant modifications to mod_include > could be done in a dev_mod_include_rewrite tag, and only when completed > are they cvs merged into cvs main. > > surely that's not too much process to cause more pain than the benefits > are worth, neh?
There is a lot of resistance to using tags and branches the way you suggest Luke. I believe it has already received a -1 on this list at some point, but I would have to look. There are a lot of people who would agree with you that branching is a good thing, we just need to figure out how to address the concerns that other people have. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
