Hej,

many of us experience now since more that a week access problems to the
svn repositories. I saw that one repository was updated, and contacted
the author, Dan Gisselquist. Turn out that, after some trial and error,
used https. And indeed, while

  svn co --username ... http://opencores.org/ocsvn/{design}/{design}

still usually hang or are incomplete (and ping responses stop too), using a

  svn co --username ... https://opencores.org/ocsvn/{design}/{design}

simply works as it should, and at usual speed. 
Thanks to Dan for pointing this out !!

So I immediately relocated my working copy with

   svn relocate http: https: .

and re-tried the commit I wanted to do since a week. Now I get

  svn ci -F ../message.txt .
    Sending        Makefile
    Sending        doc
    Adding         doc/.cvsignore
    ...
    Sending        rtl/ibus/ibdr_sdreg.vhd
    Sending        rtl/ibus/iblib.vhd
    Deleting       rtl/make
    Adding         rtl/make_ise
    svn: E175002: Commit failed (details follow):
    svn: E175002: COPY request on '/ocsvn/w11/!svn/bc/27/w11/trunk/rtl/make' 
                  failed: 502 Bad Gateway

So the connection works, but the commit is aborted. Some googling shows 
that this a common and known problem with has to be addressed in the 
Apache configuration. See for example
  http://blog.pierreroudier.net/2013/09/svn-copy-and-502-bad-gateway/

So it seems that OpenCores is currently broken for two reasons:

1. http access doesn't work because apparently a packet filter runs amok.
   When I do a 'svn co ... http://opencores.org/ocsvn/...' even ping 
   responses from opencores.org stop, but only for pings from the node who 
   started the svn. From other nodes ping still works. That shows that some 
   mechanism specifically suppresses for some time data exchange between 
   these two nodes. Doing a traceroute even shows where this happens. A 
   healthy traceroute ends in

      9  vst-ncore-1.bundle-ether6.tele2.net (130.244.71.179)                    
     10  vst-pe-1.port-channel1.tele2.net (130.244.39.47)
     11  212.247.178.10 (212.247.178.10)          
     12  * * *
     13  e068.broadband2.quicknet.se (92.43.36.68)  

   The node e068.broadband2.quicknet.se is hosting 'opencores.org'.
   A traceroute right after a blocking 'svn co ... http: ...' ends in

      8  kst5-core-1.hundredgige0-2-0-0.tele2.net (130.244.39.29)
      9  vst-ncore-1.bundle-ether6.tele2.net (130.244.71.179)
     10  vst-pe-1.port-channel1.tele2.net (130.244.39.47)

   so the hoop to '212.247.178.10' is missing. Apparently this node is 
   causing the problems, that is three hops in front of opencores.org.
   IT is clearly speculation, but is seems that some intrusion detection 
   with deep packet inspection is running wild here.

2. switching to https: as transport apparently avoids this (and when my
   speculation is true it is clear why). But now the Apache configuration
   seems not to be adequate for handling https and needs to be modified.

The first problem is apparently somewhere on the ISP side and may be hard 
to trace and resolve. But the second one seems to be quickly resolvable.

I'd very much appreciate if the OC Team has a look at this, checks whether 
https is a good work around of the ISP issues, fix the Apache configuration, 
and if all works out, please make a prominent statement  on the home page 
about the current problems and the work around.

          With best regards,   Walter