[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SWIG client bindings and auth_baton

From: Philipp von Weitershausen <philipp_at_weitershausen.de>
Date: 2003-05-12 16:15:23 CEST

Hi Stephen,

> However the code I'm looking at (gsvn) uses
> client.new_svn_client_auth_baton_t() - which doesn't seem to exist in
> thie current bindings.
>
> Without this function I can't see any way to create an auth_baton_t with
> which to populate the client_ctx, and without doing that things tend to
> segfault. Or at least that's why I think they're segfaulting.

The way to create an auth_baton now is to call util.svn_auth_open().
Consider the following script:

from svn import client, util

# create a pool; yes, this is quite disturbing for python programmers
pool = util.svn_pool_create(None)
# create a list of authentication providers for the auth baton
providers = [
     client.svn_client_get_simple_prompt_provider(pool),
     client.svn_client_get_simple_provider(pool)
     ]

# create the auth baton
auth_baton = util.svn_auth_open(providers, pool)

# create a client context (svn_client_ctx_t) to pass it to client
# functions
client_ctx = client.new_svn_client_ctx_t()

# attach the auth baton to the context
# WARNING: this might change due to my patch that I sent in recently
# (wonder when I might get some response for it)
# because using accessor functions really is ugly
client.svn_client_ctx_t_auth_baton_set(client_ctx, baton)

# we need a new revision
rev = util.new_svn_opt_revision_t()
svn_opt_revision_t_kind_set(rev, util.svn_opt_revision_head)

# now do something (e.g. checking something out)
client.svn_client_checkout(
     "file:///my/rep",
     "trunk",
     rev,
     1, #recursive
     client_ctx,
     pool
     )

There you go. As I said in the comment, I have supplied a patch this
weekend to eliminate these evil accessor functions. Structs are
represented as classes then which is much nicer. It makes the code much
cleaner and helps people understand the API better. I'm still waiting
for the discussion on it, though

Cheers,
Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 12 16:15:07 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.