WorkingTree.wt.get_config_stack and BzrDirConfig

[Vincent Ladeuil]

>>>>> Aaron Bentley <aaron at aaronbentley.com> writes:

<snip/>

    > child_submit_to was also supposed to provide a default.  The
    > repository no-working-trees file has a similar configuration effect.

That's not what I was referring to: 'default_stack_on' provides a default
value for 'stacked_on_location'. That's the only case I know where one
option is used *only* to provide a default value for another option
instead of relying on the declarations provided by the user as he sees
fit in a config stack.

<snip/>

    > Launchpad does not create the file after the branch's bzdir is
    > created, it (effectively) creates the file after the *project* (or
    > package) is created.

Whatever, neither 'project' nor 'package' exists as a concept in bzr
(yet) as a configurable entity. It's a launchpad specific concept so
far.

<snip/>

    > I don't think that it's especially valuable to Launchpad.  I think it
    > just simplifies Bazaar configuration by having a single per-location
    > config, whether configuring a branch, tree or repository.

That's true for a standalone branch only. If I use a lightweight
checkout for a branch in a shared repository I still end up with three
'control.conf' files. And an order has to be specified between these
files.

And if we were to use only 'control.conf' if will introduce issues when
'reconfigure' is involved, how a user will resolve the conflicts when
the files need to be merged when going from a lightweight checkout to a
branch in a shared repo to a standalone branch  ?

So I don't buy the idea that using 'control.conf' means there will be a
single config file. Moreover using a single 'control.conf' won't help to
fix http://pad.lv/185298, quite the opposite even.

The same issue occurs for http://pad.lv/430538.

In both cases what is needed is a way to set config options for a given
tree and explicitly not use 'branch.conf'.

Using a file with a name that reflect the object it configures is
simpler to remember for the user.

<snip/>

    > I strongly feel that having one way of configuring a location is
    > simpler than having four ways of configuring a location.

There should be a single way to configure a given object.

That doesn't mean that sharing config options between several objects
should be restricted.

I prefer to let the user decide where things should be configured in a
way that is the easiest for him. It could be system-wide
(http://pad/lv/419854), user-specific (~/.bazaar/defaults.conf).

Note that a *lot* of users have been confused by 'locations.conf'
overriding options.

<snip/>

    >> Of course, such a 'defaults.conf' won't scale for launchpad where 
    >> hundreds of thousands of branches are hosted, so 'control.conf'
    >> still makes sense here.

    > I don't see how it scales to a server where two different projects
    > are hosted.

2 sections in a single file works. Hundreds of thousands of sections in
a single file doesn't.

    >> And the plan is to add a dedicated config file for each of these
    >> objects with a clear focus: provide options for the associated
    >> object and also a clear hierarchy between them: a repository can
    >> provide default values for all its branches, a branch can provide
    >> default values for all its working trees and a user-specific
    >> 'defaults.conf' can provide default values when creating new
    >> objects.

    > I disagree that having multiple dedicated per-object files is simpler
    > than having a single file.  Why don't you have defaults-tree.conf,
    > defaults-branch.conf, defaults-repository.conf?
    > I think it is because one file is simpler than three.

No, it's because it makes no sense to have three files for a single
object.

What makes sense is to have pairs of files (defaults/overrides) for a
set of related objects.

locations.conf provides overrides for locations (all working trees,
branches, repositories under each location).

bazaar.conf provides defaults for all objects.

And AFAIK people care far more about defaults than about override so I
don't even plan to spend time on overrides.

    > If you can mingle tree, branch and repository configuration in
    > defaults.conf, it will be confusing that you can't mingle them in
    > the per-location configs.

You're mixing two different things here: mingling options in a single
file for a single object and mixing defaults for a set of objects.

Mixing all settings in a single file, I disagree with if only because of
the fallouts for 'bzr reconfigure'.

Mixing default values, I have no problem with that and I think using
defaults-{tree,branch,repository}.conf would be a bad idea and go
against the ability to share settings in as few places as possible.

That's what 'bzr config --all <option>' addresses: tell the user where
an option is defined and which value will be selected (the first one
displayed).

    > Not having to remember a heirarchy of file types is one of the
    > simplifications.

It's a bit like saying that you cannot use a different font in a
chapter, a section, a paragraph or a word because it's simpler to
remember to not inherit settings and just set the font on every
word.

There are use cases (and bugs) where bzr users have asked for, say,
being able to set an email per-working tree (http://pad.lv/185298) and
setting this in 'control.conf' will also apply to the branch or the
repository, defeating the user intent.

Looking at how other software handle configurations also reveals that
the tendency is to go from /etc/<mysoftware.conf> to /etc/<mysoftware>.d
with a bunch of files below that. There is even a 'dotd' software to
help address that.

So the effort shouldn't be on reducing the number of files but to make
it easy for the user to define his owns and more importantly to get
feedback on how bzr/bzrlib will handle them (bzr config --all). I have
no intent to push users to set options in a gazillion of files, I want
them to be able to set their options in the right place with a minimal
effort *iff* the default values provided by bzr/bzrlib don't fit their
needs. The emphasis should still be on providing the best defaults so
they don't have to do that.

All of that being said, the focus so far is to make sure using config
files (the existing ones) do not involve useless IOs, not adding new
files (http://pad.lv/832042).

     Vincent