Sourceforge http: (no SSL) imports now fail

[Max Bowsher]

It seems that Sourceforge have recently changed something such that bzr-svn imports on Launchpad fail if they are over http:, but work over https:.

The signature of this particular failure is:
 * error occurs during "copying revision" phase
 * error occurs within fetch.py:_fetch_revision_switch
 * error is bzrlib.plugins.svn.errors.DavRequestFailed: A Subversion remote access command failed: REPORT of '/svnroot/xxx/!svn/vcc/default': Could not read response body: Connection reset by peer (http://xxx.svn.sourceforge.net)

An example branch where this occurs is https://code.launchpad.net/~vcs-imports/adempiere/adempiere343 but there are many more.

Based on the logs of import attempts for the above-mentioned branch we can trace the change to be between 2010-11-08 and 2010-11-09.

Last successful log: http://launchpadlibrarian.net/58858145/vcs-imports-adempiere-adempiere343.log
First failure log: http://launchpadlibrarian.net/58870241/vcs-imports-adempiere-adempiere343.log

[Jelmer Vernooij (jelmer)]

It looks like sourceforge is hanging up http connections after a certain period of time.

I'm not sure if we can do much about this. It's certainly non-trivial to retry all svn operations from within bzr-svn if they fail this way.

[Jelmer Vernooij (jelmer)]

To expand on this, operations require a certain amount of state so we'd need a wrapper that tracks that state and resends it if the connection is hung up /or/ all individual call sites would have to be able to do retries.

Neither of these really appeals to me, and I think either SF should not be doing this /or/ the svn libraries should be more robust when dealing with this sort of error.

[Robert Collins (lifeless)]

We could workaround this in LP by warning about http on sourceforge imports.

[Jelmer Vernooij (jelmer)]

I think it would make sense to support a set of builtin rewrite rules for code import URLs, or built-in set of URLs to warn on.

There is a similar bug open about CVS sourceforge imports, bug 772495.