How to cache username and passwd in pysvn

Question

here is my code

#!/usr/bin/python
# -*- coding:utf-8 -*-
import sys
import pysvn
def main():
    client = pysvn.Client()
    client.callback_get_login = lambda realm, username, may_save:(True, "myusername", "mypasswd", True)
    print client.cat('http://svn.mydomain.com/file1.py')
    print client.cat('http://svn.mydomain.com/file2.py')
    return 0

if __name__ == "__main__":
    sys.exit(main())

and I noticed that pysvn established two HTTP sessions, but in each session, it first tried a OPTION method without the "Authorization" header, after the server response 401, it sent "Authorization" header.

Since the two url is in the same domain, why not pysvn send the username/passwd directly in the subsequence sessions?

I have this question because I'm suspecting that too much 401 made my svn server failed to response. And the svnkit in eclipse works just fine and send "Authorization" header automatic.

Edit: to Alex Martelli:

try passing an explicit path to a known-to-be-writable config dir when you call Client.

tried, not work

it may be that the serving is sending different realms for the two files

the realms of two response is the same.

It looks like pysvn calls "svn_client_cat2()" from libsvn and this function does not cache username/passwd between invoking even for the same url and same realms. So I don't think I can do any more to this problem, adding new interface to libsvn and cache username/passwd for future actions will cost too much time for my task. Thanks anyway!

Answer 1

Looks like (bug hypothesis number one) the configuration directory might be not writable -- try passing an explicit path to a known-to-be-writable config dir when you call Client.

If that doesn't help (bug hypothesis number two) it may be that the serving is sending different realms for the two files (the fact that it's the same domain doesn't stop the server from doing that, though it would be a peculiar configuration choice or configuration error on the server's part... but then a server that fails due to "too many 401s" does have something peculiar anyway, so it's a suspect already;-).