title: Can't connect to Wordpress SVN server to update repository
body: <p>Okay, for some reason this morning, I am unable to connect to the Wordpress SVN repository and execute basic svn commands (e.g. <code>checkout</code>, <code>update</code>).</p>
  
  <p>Here's an example of what's happening:</p>
  
  <pre><code>$ svn co http://svn.automattic.com/wordpress/tags/3.3/
  # Adds a bunch of files...
  
  svn: warning: Error handling externals definition for '3.3/wp-content/plugins/akismet':
  svn: warning: PROPFIND of '/!svn/vcc/default': could not connect to server (http://plugins.svn.wordpress.org)
  Checked out revision 19597.
  
  $ cd 3.3
  $ svn update
  svn: OPTIONS of 'http://svn.automattic.com/wordpress/tags/3.3': could not connect to server (http://svn.automattic.com)
  </code></pre>
  
  <p>Yet, when I perform these same commands on a development server I have (a Linode VPS) it works fine.</p>
  
  <p>I've google around about this quite a bit, and found pages like these:</p>
  
  <ul>
  <li><a href="http://vsingleton.blogspot.com/2008/04/svn-propfind-request-failed-on.html" rel="nofollow">http://vsingleton.blogspot.com/2008/04/svn-propfind-request-failed-on.html</a></li>
  <li><a href="http://wordpress.org/support/topic/cant-connect-to-the-pluginssvnwordpress-server" rel="nofollow">http://wordpress.org/support/topic/cant-connect-to-the-pluginssvnwordpress-server</a></li>
  </ul>
  
  <p>A lot of these articles say something to effect of, it's your proxy server. Well, I'm not behind a proxy server:</p>
  
  <p><a href="http://whatismyipaddress.com/proxy-check" rel="nofollow">http://whatismyipaddress.com/proxy-check</a></p>
  
  <pre><code>Proxy server not detected.
  
  IP  24.21.xxxx.xxx
  rDNS    FALSE
  WIMIA Test  FALSE
  TOR Test    FALSE
  Loc Test    FALSE
  Header Test FALSE
  DNSBL Test  FALSE
  </code></pre>
  
  <p>Just a regular old Comcast home internet connection.</p>
  
  <p>Also, I can browse the wordpress SVN repository just fine via my browser.</p>
  
  <p>Anyhow, I'm sort of at a dead end here, and I guess I'm wondering if anyone has any suggestions as to how to either solve the issue or work around it? I tried setting up an forward proxy server on the Apache installation I have running on that dev server and then updating my ~/.subversion/server file, but that didn't work or I configured something wrong.</p>
  
  <p>Well, if anyone has any brilliant ideas or explanations, I'd love to hear them...</p>
  
  <p><strong>Update</strong></p>
  
  <p>I had a co-worker test this out on his home connection -- he uses Comcast as well. He got the <em>same</em> error as I did. So it appears to be some Comcast-related issue specific to the Wordpress svn repository. I was able to checkout other public repositories via http (e.g. from Google Code) just fine.</p>
  
  <p>I ran a series of tests and I could not find any hidden proxies or cache servers between me and the repository.</p>
  
  <p>I did run traceroute per Lazy Badgers suggestion, and here's what I got:</p>
  
  <pre><code>$ traceroute svn.automattic.com
  traceroute to svn.automattic.com (72.233.56.196), 64 hops max, 52 byte packets
   1  192.168.1.1 (192.168.1.1)  0.659 ms  0.292 ms  0.185 ms
   2  * * *
   3  te-5-7-ur01.hollywood.or.bverton.comcast.net (68.85.150.225)  8.792 ms  8.309 ms  9.054 ms
   4  xe-3-1-0-0-ar03.beaverton.or.bverton.comcast.net (68.87.216.33)  14.354 ms  24.859 ms  8.753 ms
   5  pos-3-8-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.117)  21.869 ms
      pos-3-1-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.113)  21.791 ms
      pos-3-0-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.109)  22.983 ms
   6  pos-0-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.85.46)  23.682 ms  25.043 ms  24.675 ms
   7  xe-10-3-0.edge1.sanjose1.level3.net (4.71.118.5)  61.048 ms  23.986 ms  24.221 ms
   8  vlan80.csw3.sanjose1.level3.net (4.69.152.190)  25.257 ms  25.648 ms
      vlan90.csw4.sanjose1.level3.net (4.69.152.254)  24.310 ms
   9  ae-82-82.ebr2.sanjose1.level3.net (4.69.153.25)  24.870 ms
      ae-92-92.ebr2.sanjose1.level3.net (4.69.153.29)  25.371 ms
      ae-91-91.ebr1.sanjose1.level3.net (4.69.153.13)  24.744 ms
  10  ae-34-34.ebr4.sanjose1.level3.net (4.69.153.34)  36.011 ms  25.975 ms  36.053 ms
  11  ae-5-5.ebr2.sanjose5.level3.net (4.69.148.141)  25.236 ms  25.307 ms  25.305 ms
  12  ae-6-6.ebr2.losangeles1.level3.net (4.69.148.201)  31.299 ms  34.076 ms  33.401 ms
  13  ae-3-3.ebr3.dallas1.level3.net (4.69.132.78)  59.012 ms  58.604 ms  60.576 ms
  14  ae-83-83.csw3.dallas1.level3.net (4.69.151.157)  59.708 ms  65.724 ms
      ae-73-73.csw2.dallas1.level3.net (4.69.151.145)  60.383 ms
  15  ae-42-90.car2.dallas1.level3.net (4.69.145.196)  60.636 ms
      ae-22-70.car2.dallas1.level3.net (4.69.145.68)  59.572 ms  59.758 ms
  16  databank-ho.car2.dallas1.level3.net (4.71.170.2)  58.711 ms  59.994 ms  60.561 ms
  </code></pre>
  
  <p>I don't know if that's unusual or anything. I tried the same on my dev sever and the result looked mostly similar, save for line 2 with the * * *.</p>
  
  <p>I successfully configured a forward proxy on my dev server so I've hacked together a solution for now, but I still don't quite understand what is afoot...</p>
  
  <p><strong>Update 2</strong></p>
  
  <p>In response to a question, here's how I configured things to use my dev server as a proxy for the time being.</p>
  
  <p>First, I configured apache on my dev server to run as a proxy. Make sure these directives are somewhere in your Apache configuration file chain (httpd.conf, vhosts.d directory, etc.):</p>
  
  <pre><code>Listen 8080
  
  &lt;VirtualHost _default_:8080&gt;
      ProxyRequests On
      ProxyVia On
      ProxyPreserveHost On
  
      &lt;Proxy *&gt;
          Order deny,allow
          Deny from all
          Allow from xxx.xxx.xxx.xxx
      &lt;/Proxy&gt;
  &lt;/VirtualHost&gt;
  </code></pre>
  
  <p>This assumes you have a working Apache set up on a development server somewhere (I would definitely not use this on a production server) with mod_proxy installed. Port 8080 is arbitrary. Basically for an unmatched virtual host (i.e. any request that doesn't match your other hosts you have set up) it will turn proxy on and proxy the request through. Change "xxx.xxx.xxx.xxx" to your own IP address.</p>
  
  <p>Now you have to change the server setting in your subversion config file.</p>
  
  <p>In this file:</p>
  
  <pre><code>~/.subversion/servers
  </code></pre>
  
  <p>Find this section:</p>
  
  <pre><code>[global]
  # http-proxy-exceptions = *.exception.com, www.internal-site.org
  # http-proxy-host = proxy1.some-domain-name.com
  # http-proxy-port = 80
  # http-proxy-username = defaultusername
  # http-proxy-password = defaultpassword
  # http-compression = no
  # http-auth-types = basic;digest;negotiate
  # No http-timeout, so just use the builtin default.
  # No neon-debug-mask, so neon debugging is disabled.
  # ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
  </code></pre>
  
  <p>Uncomment out <code>http-proxy-host</code> and <code>http-proxy-port</code>. For host use a spare domain name you have mapped to your development server or presumably you could just use your server IP. Then set the port to 8080 or whatever you used.</p>
  
  <p>This should route all subversion http requests via your proxy you just set up. It doesn't affect svn or svn+ssh requests.</p>
  
  <p>This was my quick hack, your mileage may vary, this might be totally insecure or broken, etc.</p>