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.s_at_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!
Received on 2013-02-17 03:07:48 CET