svn http/https transport

[Jelmer Vernooij]

Ricardo Kirkner wrote:
>>> 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

I probably got some of the details wrong, this was from memory. Perhaps
it also requires a "username = " setting.

>> 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.

Well, that's what I mean - bzr should allow fallback credential stores
to be registered and bzr-svn could register one that looks at ~/.subversion.

> 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.
If Bazaar allowed multiple transports then the first transport (the
"native Bazaar" transport) would still prompt the user for credentials,
so I don't see how this would help the problem. If the http transport
used a common mechanism for retrieving credentials (which could include
checking ~/.subevrsion) then you wouldn't be prompted at all.

Cheers,

Jelmer