I had exactly this same problem the other day (when checking out various JBoss SVN projects first the first time). My Linux workstation has direct NATed internet connectivity, but my Windows XP workstation must use a proxy (both HTTP/SOCKS5 are available). I found that my WinXP box was unable to checkout from SVN due to the use of the HTTP verb "REPORT" which my HTTP proxy does not support. To fix this problem I disabled the HTTP proxy (in WinXP) leaving only the SOCK5 proxy and then my SVN clients (TortoiseSVN / Eclipse SVN) worked fine. My proxy I was using was Apache Squid (2.5.STABLE9). Maybe this additional WebDAV verb can be enabled in this version of squid but the default configuration does not allow it. Maybe it would be helpful to have this known issue listed with all SVN usage instructions. http://docs.jboss.org/process-guide/en/html/svnaccess.html http://www.jboss.org/community/wiki/SVNRepository Another factor to look into is did SVN always work this way, or has a recent change in client/protocol cause people to think JBoss infrastructure is at fault (because the same setup client side setup works to another public SVN server) ? Darryl Steve Ebersole wrote: > What does pike my interest is that he mentioned it worked ok for HTTPS > but HTTP is giving him grief. This leads me to believe that the problem > may actually be a web proxy between the user and their internet > connection. Typically web proxies will connect HTTPS traffic straight > through (for obvious reasons) but sometimes they can have problems with > SVN if they are configured to not allow some HTTP request methods. > > Can we please get the user to confirm that they have no proxy server > (squid, Microsoft ISA, etc.) between themselves and their internet at > large, and possibly even try to perform the operation from a place they > are sure they have a direct internet connection (like home) and see how > they go.