PySVN - Determine if a repository exists

I'm writing a small script that manages several SVN repositories. Users pass through the ID of t开发者_运维知识库he repository they want to change (the root of the repos are of the form https://www.mydomain.com/).

I need to check if the given repo actually exists. I've tried using Client.list to see if I can find any files, like so:

client = pysvn.Client()
client.list("https://.../<username>/")

But if the repo does not exist then the script hangs on the list line. From digging through the tracebacks it looks like pysvn is actually hanging on the login credentials callback (client.callback_get_login - which I have implemented but omitted, it does not fail if the repo exists).

Can you suggest how I can determine if a repo exists or not using pysvn?

Cheers,

Pete

I couldn't reproduce your hanging in credentials callback problem, so it might need an expanded description of the problem. I'm running pysvn 1.7.2 on Ubuntu 10.04, Python 2.6.6.

When I try to list a non-existent remote repository with client.list() it raises an exception. You could also use client.info2() to check for existence of a remote repository:

head_rev = pysvn.Revision(pysvn.opt_revision_kind.head)
bad_repo = 'https://.../xyz_i_dont_exist'
good_repo = 'https://.../real_project'
for url in (bad_repo, good_repo):
    try:
        info = client.info2(url, revision=head_rev, recurse=False)
        print url, 'exists.'
    except pysvn._pysvn_2_6.ClientError, ex:
        if 'non-existent' in ex.args[0]:
            print url, 'does not exist'
        else:
            print url, 'error:', ex.args[0]

Peter,

My team and I have experienced the same challenge. Samplebias, try providing a callback_get_login function but set your callback_server_ssl_trust_prompt to return (True, trust_dict['failures'], True). IFF subversion has not cached your server certificate trust settings, then you may find the info2() (or Peter's list() command) hangs (it's not actually hanging, it just takes intermittently much longer time to return). Oddly, when you CTRL-C the interpreter in these scenarios, you'll get indication that it hung on the login callback, not the server_cert verification. Play around with your ~/.subversion/auth settings (in particular the svn.simple and svn.ssl.server directories) and you'll see different amounts of 'hang time'. Look at pysvn.Client.callback_cancel if you need to handle situations which truly never return.

Considering: http://pysvn.tigris.org/docs/pysvn_prog_ref.html#pysvn_client_callback_ssl_server_trust_prompt you need to decide what your desired behavior is. Do you want ONLY to allow those connections for which you already have a cached trust answer? Or, do you want to ALWAYS accept regardless of server certificate verification (WARNING: this could (obviously) have negative security implications). Consider the following suggestion:

import pysvn

URL1 = "https://exists.your.org/svn/repos/dev/trunk/current"
URL2 = "https://doesntexit.your.org/svn/repos/dev/trunk/current"
URL3 = "https://exists.your.org/svn/repos/dev/trunk/youDontHavePermissionsBranch"

ALWAYS = "ALWAYS"
NEVER = "NEVER"

DESIRED_BEHAVIOR = ALWAYS

def ssl_server_certificate_trust_prompt(trust_dict):

if DESIRED_BEHAVIOR == NEVER:
    return (False, 0, False)
elif DESIRED_BEHAVIOR == ALWAYS:
    return (True, trust_dict['failures'], True)
raise Exception, "Unsupported behavior"

def testURL(url):
    try:
        c.info2(url)
        return True
    except pysvn.ClientError, ce:
        if ('non-existant' in ce.args[0]) or ('Host not found' in ce.args[0]):
            return False
        else:
            raise ce

c = pysvn.Client()
c.callback_ssl_server_trust_prompt = lambda t: (False, t['failures'], True)
c.callback_get_login = lambda x, y, z: (True, "uname", "pw", False)

if not testURL(URL1): print "Test1 failed."

if testURL(URL2): print "Test2 failed."
try:
    testURL(URL3)
    print "Test3 failed."
except: pass

In actuality, you probably don't want to get as fancy as I have with the return values. I do think it was important to consider a potential 403 returned by the server and the "Host not found" scenario separately.