svn http/https transport

[Jelmer Vernooij]

Ricardo Kirkner wrote:
> Jelmer Vernooij wrote:
>
>>> 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.
>> I don't think that's necessary. The overhead is very very small though
>> because all the extra work is accessing a couple of extra local files
>> (it'll be a few ms at most), there is no network traffic involved. This
>> overhead will only happen if the branch requires authentication *and*
>> Bazaar didn't have credentials available itself, so it would have to
>> prompt anyway if it didn't check the svn cache. Also, storing and
>> retrieving what credentials store to use and then checking it will
>> probably be just as expensive as checking both credential stores.
>
> yes, if we assume we only want to check against these two stores. What
> if we would like to use a third (or fourth) optional store? (i am
> thinking of ldap here, for example). Then the cost of checking those
> additional stores would not be negligible, and so, another approach
> would have to be taken.
Yeah, I agree - in the case of LDAP you might want to not have it as a
fallback but require explicit configuration in authentication.conf,
mainly because it is significantly slower than using the (local)
Subversion store.
> Now that I said that, I am beginning to think: this is what the
> authentication.conf file was created in the first place, right? :-)
> and the svn case is just a special case that is so common that we
> don't want it to be treated as special anymore...
>
> I might be confusing a lot of people with my emails, but its helping
> me out to better understand bzr :-)
>
> thanks for all the support
No worries. Of course, if you'd be interested in helping implement this
fallback mechanism, let us know :-)

Cheers,

Jelmer