Daniel, Thank you for prompt response. I'm sorry I haven't returned the courtesy. I'm a full time student and I work with two jobs. One of them is closing on the ship date for their first product so things are busy. I copied and pasted material from your first email, to put the answer into one. Is that okay?
On Fri, Feb 1, 2013 at 11:31 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Daniel Shahaf wrote on Fri, Feb 01, 2013 at 19:15:04 +0200: >> Hi again! >> >> Ryan Vordermann wrote on Thu, Jan 31, 2013 at 13:01:19 -0700: >> > Hi, >> > >> > My name is Ryan. I'm not subscribed to this list so I would appreciate >> > being CC'ed on responses >> > >> > I'm working on a utility that uses the svn client api. Right now it works, >> > but I want to add support for usernames and passwords. I do not (yet) >> >> Have a look at subversion/tests/cmdline/atomic-ra-revprop-change.c . It >> supports exactly providing a (single, known-in-advance) >> username/password pair. > > I should clarify, though: that tool uses the svn_ra_* API directly, > bypassing the (higher-level) svn_client_* API. Your tool might or might > not want to do that. I found that file really helpful, but I'm still going to try sticking to the client lib. Mostly as a design choice. There isn't a reason I couldn't form deeper connection to SVN. >> > want to support any of the other security features. What are the >> > appropriate values for the following arguments to this function? >> > >> > svn_cmdline_create_auth_baton >> > >> > Currently I have this: >> > svn_boolean_t non_interactive = FALSE; >> Basically this is "may prompt". The "plaintext" and "SSL certificate" >> prompt depend on this. OH. Does this part depend a call back then for the prompt? >> > const char *config_dir = NULL; >> > svn_boolean_t no_auth_cache = FALSE; >> > svn_boolean_t trust_server_cert = FALSE; >> >> Like the corresponding arguments to the cmdline binary. >> >> > svn_config_t *cfg_config = NULL; >> > >> That's the parsed "config" file from CONFIG_DIR. I'm not quite sure why >> we have both this and 'const char *config_dir'. >> >> (Also, where do you see the name "cfg_config"? It's called "cfg" at the >> declaration and definition, in trunk.) At this point I'm not sure anymore, but I *think* it was something I read in the source for the command line. >> > Which so far works, but I was just taking a WAG. >> >> Did you read the API documentation? Was it not clear? Not at the time. I was being a bad person. My advisor said "Add this feature" and five minutes later, it was so. Since nothing crashed I just ran with it at the time. I think I get this section now though. Thank you Daniel!
