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? *shrug* :) luke ----- Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> ----- "i want a world of dreams, run by near-sighted visionaries" "good. that's them sorted out. now, on _this_ world..."
