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..."
