apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: httpd-2.0/apr/apr-util Code Freeze
Date Fri, 09 Mar 2001 14:26:03 GMT
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 Kenneth Casson Leighton <lkcl@samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."

View raw message