svn http/https transport

[Ricardo Kirkner]

Hi,

I've been working with a branch of an svn backed project that is 
exported through https. I stumbled upon a problem with bzr interacting 
with the http authentication.

There are actually two issues:

1. When no username is provided in the url, I get an error about 'Unable 
to handle http code 401: Authorization Required'
2. When the username is passed through in the URL, I always get prompted 
for the password

Now, the svn credentials are supposed to be used, because I have them 
stored in the svn credentials store, but that is not happening.

I tried several alternatives:

1. Use svn+http(s)

This works alright. The svn credentials are being used, but I get a 
deprecation warning, telling me I should instead use http(s) directly 
(which doesn't work)

2. Use authentication.conf

This works too, but the drawback is that I have to manuall register the 
authentication tokens for every project I want to track.

I did follow the transport code, and what I found was:

The SVN transport code is actually never called, as the only transport 
registered for http/https are pycurl and urllib.

I tried to register the http/https protocol with the SvnRaTransport 
class, and it started working; I did not get the username/password 
requested anymore, as the svn credentials where being taken from the 
store. The problem here was that the normal http/https transport (using 
pycurl/urllib) was now broken, and it would always try to use 
SvnRaTransport for http/https urls.

The problem here is that whenever a transport fails, bzr will bail out, 
and not try any other transport for that protocol.

So I suggest a thing: what if we allow bzr to try out all transports, 
until it finds one that succeeds, and only bail out if all transports 
for a given protocol fail.

This would indeed allow the svn transport to be checked first (in the 
case the svn plugin is installed), and fall back to the plain 
pycurl/urllib transport if the repo behind the webserver is not an svn repo.

This solution might be centric to the problem I was trying to solve, and 
therefore I wanted to discuss it with you guys.

The whole point behind this modification is to make the end-user's life 
easier, and to allow a cleaner and easier migration path for svn users.

Ricardo