[PING][RFC][MERGE] alias to respect spaces in quoted arguments

Aaron Bentley aaron.bentley at utoronto.ca
Mon Nov 27 14:45:29 GMT 2006

Hash: SHA1

Marius Kruger wrote:
> My conclusion was thus that every time config.GlobalConfig ()
> is called, that the config is read anew. I would like us to
> store a instance of the GlobalConfig config somewhere,
> and just load it (lazily) and use the same instance everywhere,
> so that we don't parse the file a million times.

I don't think we do parse the file a million times, though.  Certainly,
if we did, that sort of thing would show up on benchmarks.

> I was thinking something like :
> (in bzrlib/config.py)
> _global_config=None
> def get_global_config():
>     if _global_config is not None:
>         _global_config = config.GlobalConfig()
>     return _global_config

When converting a file-backed value into a memory-cached value, you must
be careful not to change its behavior.  You would need to test that when
bzr sets a value in the global config:
1. that value is written to disk
2. that value is immediately available to bzr

It's also worth considering whether we want the in-memory values to
change when the file is updated externally.  The semantic thus far is
that they would.  The config directory thus far doesn't support any
locking, so we can't use that as a hint.

Also, if you're considering lazy-loading bazaar.conf, the same mechanism
ought to be used for locations.conf, which is usually queried before
bazaar.conf.  This suggests that caching the GlobalConfig object is too
high-level; LocationConfig has a parameterized constructor, so it can't
be cached effectively.  Instead, it might be preferable to cache the
ConfigObj returned by IniBasedConfig._get_parser

>     > I also think it should be possible to set branch specific aliases,
>     > where the branch specific one over-rides the global one.
>     > I'll look into supporting this, If thats ok.
>     This seems error-prone and confusing to me, how do you intend to use it?
> Like you can set branch specific user-email (whoami),
> I can imagine that you might want to do interesting aliases which
> might only be appropriate for a specific  branch,
> for example you might want a  particular branch to
> output its diff differently, with some funny diff options or something..

This doesn't sound convincing to me.  My experience with similar systems
is that they aren't very helpful, because it's easy to forget precisely
which behaviors are enabled for which locations.  So you tend to specify
things that may-or-may-not be enabled for the current location, anyhow.

It's even problematic for the location values like 'pull/merge
location', 'push location', 'bound location' and 'submit location',
which is why the dev version of bzrtools includes a 'show-paths' command
(by Alexander Belchenko) to remind you.

ConfigObj supports nesting, so per-location aliases are certainly
possible, but I don't think they're useful.

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list