svn http/https transport

[Ricardo Kirkner]

Jelmer,

>>
>> 1. When no username is provided in the url, I get an error about 'Unable
>> to handle http code 401: Authorization Required'
> This issue is also in the bug tracker as bug 256612. I've
> (coincidentally) posted a patch to the list earlier this week, which
> will make Bazaar prompt if there is no username it knows it can use:
> 
> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090331142523.17D6857B84%40charis.vernstok.nl.vernstok.nl%3E
> 

great. this was an issue, but (at least for me), not the most important 
one of the ones I described.

>> 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.
> 
> bzr-svn contains a authentication credentials provider that can retrieve
> credentials from ~/.subversion. However, given the way the
> authentication settings in Bazaar work at the moment, you have to
> explicitly specify that Bazaar should use the Subversion credentials
> provider for a particular host, I think something like:
> 
> [host1]
> host = host
> password_encoding = subversion
> 

this is currently not working for me. I am still getting the error about 
'Authorization Required' from the http handler.

The only way I get it to work is if I explicitely set the username and 
password.

> It would of course be nice if Bazaar could always see if there are
> credentials in the Subversion cache that apply rather than requiring
> this redirect, see https://bugs.edge.launchpad.net/bzr/+bug/321918 for
> details. With this bug fixed, there should be no need to register
> bzr-svn's Transport class as the primary http transport (which also
> breaks all non-svn http operations).
> 

I don't think bzr should always check subversion's credentials store, 
but only if the bzr-svn plugin is installed.

Right now, as I understand it, there is no much point in having several 
transports registered for one protocol, as only one will be executed 
(the first one that imports correctly).

What I was suggesting is that the transport mechanism should behave 
using fallbacks (i.e. it should try each transport available until one 
transport succeeds, instead of failing whenever the first mechanism 
fails), and fail only if all transports failed. This adds a little 
overhead, but gives more flexibility.

That way, if the svn plugin is installed, the svn http transport is 
queried first, thus checking the svn credential store, and if that fails 
(if the branch queried is not an svn branch, or there are no credentials 
stored for that branch), it should continue with whatever transport is 
available (for example, the default urllib transport).

If I am missing something, please be so kind as to point it out.

Regards,

Ricardo