Code review comment for lp:~vila/bzr/832036-stack-registry

> Can you explain a bit what the stacks make possible, and what use cases they
> cover?

Pfew, quite a lot already, see
http://doc.bazaar.canonical.com/devnotes/configuration.html for
the full story ;)

But talking about already available features: they are associated
with an optional MutableStore and a given section where the
modification can occur. They are also associated with a list of
sections across multiple stores where option values can be
defined. Each stack can define its own rules about selection and
ordering for these sections.

As such, they already support the old GlobalConfig and
BranchConfig (except for the point you raised about bzr-svn
injecting its own branch config to allow subversion.conf sections
to be supported).

They can also support more config files/contexts depending on
what we decide:

- config stacks for repositories and working trees,
- system-wide config file,
- defaults and overrides config files (the later being
  locations.conf today, the former existing for UUIDs svn repos
  via subversion.conf only today),
- etc

I didn't push for more features nor make the existing ones
covering more than what was needed for the migration, but they
already offer a greater flexibility than the existing ones.

> I don't really understand why this all needs to be in a registry rather
> than e.g. just having the relevant context objects provide their own stack
> (Branch.get_config_stack()?), like we do for config at the moment.

Several reasons:

- the actual design is a mix of transport/local files APIs, that
  makes it hard to have a consistent behavior for all config
  files (some existing classes don't even provide a way to remove
  an option for example).

- creating config objects on the fly, makes it hard to share the
  some config files as far as IOs is concerned (which means you
  generally need to read bazaar.conf, locations.conf and
  branch.conf each time you want to query the config for a given
  option),

- using classes instead of a registry didn't scale well in the
  past in other areas.

But in the end, using a registry mean you can implement
Branch.get_config_stack() by getting the stack from the registry ;)