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

Re: svn commit: r1382028 - in /subversion/trunk/subversion: include/svn_config.h libsvn_subr/cmdline.c libsvn_subr/config_file.c

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 7 Sep 2012 11:09:03 -0400

On Fri, Sep 7, 2012 at 10:51 AM, C. Michael Pilato <cmpilato_at_collab.net>wrote:

>
> I may be wrong, but I kinda get the sense that the GUI clients take their
> pick of which Subversion runtime config options make sense for them to
> honor. At the moment, the only code which honors the state of the new
> configuration variable is the svn_cmdline_* stuff that builds the initial
> auth baton. I can't imagine that TSVN and other GUI clients which such
> slick UI features use that function -- which is strictly aimed at
> command-line utility -- anyway. So can you simply still choose to
> unconditionally add the client-cert prompt provider to the TSVN auth baton
> provider array?
>

Setting aside Stefan's feedback on the default which sounds valid ...

JavaHL clients like Subclipse are using libsvn_client. I know that for
some of the stuff like the auth providers, the JavaHL C++ code is
recreating some of what is in the command line client, so I am not sure if
that covers this.

As a JavaHL users, I expect the runtime configuration options to be applied
for me the same way they are for the command line client. So I would
expect the JavaHL C++ code to be doing whatever is needed so that this
option is honored. Whether the default is yes or no would be a secondary
question. I would expect a user to be able to edit the file to set the
behavior.

If TortoiseSVN will not be impacted by the default, then I would still be
OK with leaving it as you have it.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-09-07 17:09:35 CEST

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.