RE: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Thanks Trent i will give this a go. On the seond co did you not mean to checkout the apr-util/trunk ? or do i need to checkout apr twice ? Trent Nelson [EMAIL PROTECTED] 12/21/2006 07:51 AM Please respond to dev@httpd.apache.org To dev@httpd.apache.org cc Subject RE: Apache BUG: 36495 : ajp_proxy_connect_backend failure Here's how I build trunk: $ mkdir -p apr/apr $ mkdir apr/apr-util $ mkdir -p httpd/trunk $ cd apr/apr $ svn co http://svn.apache.org/repos/asf/apr/apr/trunk $ cd ../apr-util $ svn co http://svn.apache.org/repos/asf/apr/apr/trunk $ cd ../../httpd $ svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk I'll be happy to push the above into a page under httpd.apache.org/ dev as here's how to build HEAD for testing if folks think it useful. Or I may put it on my blog. I find that svn externals can provide a useful alternative to the approach you've mentioned: F:\scm\svn\svn.onresolve.com\contrib\trunk\httpd\trunksvn pl -v Properties on '.': svn:externals : src http://svn.apache.org/repos/asf/httpd/httpd/trunk src/srclib/apr http://svn.apache.org/repos/asf/apr/apr/trunk src/srclib/apr-iconv http://svn.apache.org/repos/asf/apr/apr-iconv/trunk src/srclib/apr-util http://svn.apache.org/repos/asf/apr/apr-util/trunk src/srclib/zlib https://svn.onresolve.com/contrib/tags/zlib-1.2.3.1 src/srclib/openssl https://svn.onresolve.com/contrib/tags/openssl-0.9.8d.1 src/modules/contrib/mod_auth_sspi https://svn.onresolve.com/contrib/tags/httpd-mod_auth_sspi-1.0.4-2.2.2.1 /src Tell you what would be nice: svn.apache.org/repos/asf/httpd/httpd/views/ trunk/ 2.0.x/ Where each 'view' is simply an empty directory with the relevant svn externals set for building that particular branch. That way, all you'd need to do to get a buildable trunk is: svn co http://svn.apache.org/repos/asf/httpd/views/trunk Trent. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Trent Nelson wrote: I'll be happy to push the above into a page under httpd.apache.org/ dev as here's how to build HEAD for testing if folks think it useful. Or I may put it on my blog. I find that svn externals can provide a useful alternative to the approach you've mentioned: Externals are evil. They are *very* prone to mis-tagging. A tag with externals pointing back to another leaf of a trunk are WORTHLESS. Several projects have been guilty of this. Also we don't require you to grab the latest apr... httpd trunk (so far) builds with apr 1.2.x. Someday it will require 1.3.x but that will be after at least 1.3.0 has shipped and can be installed. Which means - grab apr trunk *if you want*. I keep apr-0.9/1.2/1.x trunk checked out (ditto -util/-iconv) and just symlink from within httpd-2.0/2.2/2.x trunk. Since checkouts into the subdir don't update very well, I just svn up httpd-* apr-* from my root. It makes it much easier to move patches from version to version of our 'srclib's.
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Trent Nelson wrote: Tell you what would be nice: svn.apache.org/repos/asf/httpd/httpd/views/ AHHH - ok, retracting my statement... your approach is much less prone to mis-tagging. However, it can still yield some pretty obtuse commits if one is not careful :)
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
On Dec 21, 2006, at 12:37 AM, William A. Rowe, Jr. wrote: Trent Nelson wrote: Tell you what would be nice: svn.apache.org/repos/asf/httpd/httpd/views/ AHHH - ok, retracting my statement... your approach is much less prone to mis-tagging. However, it can still yield some pretty obtuse commits if one is not careful :) That's simple: don't make that view writable. It'd be a read-only service for folks that want to check out something buildable. It'll still make you configure and build apr + apr-util every time you make a change to httpd. Which is my main motivation to keep them out of my tree. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
RE: Apache BUG: 36495 : ajp_proxy_connect_backend failure
Tell you what would be nice: svn.apache.org/repos/asf/httpd/httpd/views/ AHHH - ok, retracting my statement... your approach is much less prone to mis-tagging. However, it can still yield some pretty obtuse commits if one is not careful :) That's simple: don't make that view writable. It'd be a read-only service for folks that want to check out something buildable. Indeed; it provides a nice easy way for people wanting to do local builds, not necessarily developers doing hardcore development (who would have the savvy to set up the development environment any which way they want). Any chance of trialing this view approach for trunk? Wouldn't take more than a couple of minutes to set up... Trent.
RE: Apache BUG: 36495 : ajp_proxy_connect_backend failure
I find that svn externals can provide a useful alternative to the approach you've mentioned: Externals are evil. They are *very* prone to mis-tagging. A tag with externals pointing back to another leaf of a trunk are WORTHLESS. Several projects have been guilty of this. I'd certainly agree that *tagging* a structure that contains externals pointing to other trunk branches is a recipe for disaster. As long as you don't do this, they can be very useful, even if your entire externals definition is composed of tagged/read-only branches: http://svn.apache.org/repos/asf/httpd/httpd/views/2.2.3 svn:externals: src/ http://svn.apache.org/repos/asf/httpd/httpd/tags/2.2.3 src/srclib/apr http://svn.apache.org/repos/asf/apr/apr/tags/1.2.8 src/srclib/apr-util http://svn.apache.org/repos/asf/apr/apr-util/tags/1.2.8 src/srclib/apr-iconv http://svn.apache.org/repos/asf/apr/apr-iconv/tags/1.1.1 Thus, I could check out the exact source used to build 2.2.3 via: svn co http://svn.apache.org/repos/asf/httpd/httpd/views/2.2.3 I'd personally prefer this sort of an approach to, say, relying on the source tars that are manually rolled at release time. Trent.
Re: svn commit: r488780 - /httpd/httpd/branches/2.2.x/STATUS
Roy T. Fielding wrote: So, I'm -0.9 on the patch, even though it isn't much worse than the existing code. I'd be -1 if I could be sure what it did. And I wouldn't debate it... back to the drawing board. As an improvement to the behavior I support it, in terms of style it got a -0.5 from me, but I didn't have the cycles to clean it up. Thanks for the kick in the ass to do so. It's time for the less-than-half-assed solution to WaitForMultipleObjects. Bill
