svn http/https transport

[Ricardo Kirkner]

Jelmer Vernooij wrote:
> Ricardo Kirkner wrote:
>>> 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.
>> Well, what I was thinking (from my experiments), is that the bzr default
>> mechanism gets loaded last. In our example, if the svn plugin defines a
>> new mechanism, and since the plugins get loaded 'after' the core of bzr,
>> and since when registering a new transport it gets stored as the 'first'
>> option, this effectively makes it the default option, and so, the svn
>> transport gets tried first, and eventually falls back to the bzr mechanism.
> 
> This means that Bazaar gets slower when used for "native" Bazaar
> branches if bzr-svn is loaded, and that's something I'd very much like
> to avoid. bzr-svn should not cause any significant overhead when it's
> loaded but you're not using it.

Well, yes, you're right again here. We should avoid making the default 
bzr slower at all costs.

So, to sum up, the main idea is to make bzr always use the svn 
credential store for authentication, if the bzr-svn plugin is loaded, 
and keep the current transport detection mechanism untouched.

Following the same reasoning as before, the optimal choice would be that 
bzr would use the svn credential store only if accessing a svn branch. 
In order to do that, I guess it would have to store some metadata about 
the credential store used when branched, so it can try that out first. 
This would though create some overhead that was not present so far, and 
might be desirable to avoid.

Is that right, or am I missing something again? :-)