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

Re: Mini-issue: boolean config values

From: Files <files_at_poetryunlimited.com>
Date: 2003-10-29 01:41:11 CET

I was thinking simpler.


hash containing all boolean options (function secret)
stringbuf w/ yes and no.(parse-context values)

static function is_boolean to check to see if the option is a boolean one.

static function conform_boolean to do the translation based on is_boolean.

When an option value is parsed if the option is boolean, compare for truth and
substitute the stringbuf above instead of the value when setting the option
value in the config.

Do this where the config hash for the option is set as a pass through.

Then all of the comparisons can be simply 'yes'/'no' everywhere else.

No mess, no fuss.

IMHO, the real problem is that we haven't set a policy for what a truth value
should be on parsing. But parsing should know what is valid and invalid for a
fixed set of keys which have limited context.

So the parser needs to be more intelligent and the comparators need to be more


Shamim Islam
Branko ?ibej said:
> Files wrote:
>>Can I have a stab at looking at this? It sounds like a good place to begin.
> I suggest adding two new functions to svn_config:
> void svn_config_get_bool (svn_config_t *cfg, svn_boolean_t *valuep,
>                           const char *section, const char *option,
>                           svn_boolean_t default_value);
> void svn_config_set_bool (svn_config_t *cfg,
>                           const char *section, const char *option,
>                           svn_boolean_t value);
> then use svn_config_get_bool wherever we're currently parsing the truth
> value by hand. I also suggest svn_config_get_bool should understand
> "yes"/"no", "on"/"off" and "true"/"false" pairs, and should be
> case-insensitive.
>>What issue number is this?
> I don't think there is one.
> --
> 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 Wed Oct 29 01:41:52 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.