Julian Foad wrote:
> brane@tigris.org wrote:
>
>> Author: brane
>> Date: Tue Oct 28 20:49:00 2003
>> New Revision: 7556
>
> ...
>
>> Log:
>> Add svn_config functions for parsing boolean option values.
>> Tweak svn_config_get_server_setting_int.
>
>
>> Modified: trunk/subversion/include/svn_config.h
>> ==============================================================================
>>
>> --- trunk/subversion/include/svn_config.h (original)
>> +++ trunk/subversion/include/svn_config.h Tue Oct 28 20:49:00 2003
>> @@ -91,6 +91,9 @@
>
> ...
>
>>
>> +#define SVN_CONFIG_TRUE "true"
>> +#define SVN_CONFIG_FALSE "false"
>> +
>
>
> So those are the canonical values. Are the other pairs (yes/no,
> on/off) recognised for backwards compatibility, or because it seems
> more friendly to recognise a variety of synonyms? I am hoping the
> former, because giving users lots of equivalent possibilities often
> leads in the end to more confusion rather than less. For example:
>
> sysadmin: Does your config file look like this?
> user: No. Where yours says "authentication=no", mine says
> "authentication=false". Is no authentication the same as false
> authentication?
In this case, I'd expect people to write "authentication=off". :-)
> sysadmin: Yes, they mean the same. Now, how about the rest of the file?
> user: ...
>
> I'm not going to push my argument further; I just want to gently
> discourage unnecessary flexibility.
The whole config parsing module is "unnecessary flexibility"; so are svn
command aliases. I think it makes perfect sense to allow several
different representations of truth values.
>> void svn_config_set (svn_config_t *cfg,
>> const char *section, const char *option,
>> const char *value);
>> +
>> +/** Like @t svn_config_get, but for boolean values.
>> + *
>> + * Parses the option as a boolean value. The recoginzed representations
>> + * are 'true'/'false', 'yes'/'no', 'on'/'off'; case does not matter.
>> + * Returns an error ### if the option doesn't contain a known string.
>
> @@ -157,6 +160,24 @@
>
> * Returns SVN_ERR_RA_DAV_INVALID_CONFIG_VALUE if the option doesn't
> contain a known string.
Right, I forgot to update that comment before committing. But first I'd
like to suggest that we change the name of that error code; I can't see
what makes it specific to RA_DAV.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 07:04:29 2003