WorkingTree.wt.get_config_stack and BzrDirConfig
vila+bzr at canonical.com
Mon Feb 6 10:14:32 UTC 2012
>>>>> Aaron Bentley <aaron at aaronbentley.com> writes:
> Hi there,
> I've actually just started getting familiar with config stacks this
> week, fixing a bug in bzr-pqm caused by the cutover.
> I see that you've added a way of getting a config from a
> WorkingTree, with hints that per-working-tree configs might be
> supported in the future.
> I think it's worth considering using the per-bzrdir config for
> this, rather than implementing something that only works for
> working trees.
> The BzrDirConfig is pretty obscure right now, because we only use it
> to configure the default stacking location.
Yeah, I agree it's rather obscure. And 'default' kind of hints that it's
a very special case and indeed that's the *only* option in this file and
the only option that complements another option to offer a default
Moreover it really only fits launchpad use case, when a new branch is
created, there is no way for a user to create this file *after* the
bzrdir is created but before the branch itself is created. Launchpad
manage to do that because it can provide the file and its content at
this precise point in time.
That being said, I'm not against providing support for launchpad by
adding 'control.conf' in the BranchStack (which will requires
deprecating default_stack_on and renaming it stacked_on_location so the
value there, if present, will naturally provides a default value without
the need for a special option) and later in RepositoryStack if/when we
I don't think generalizing 'control.conf' simplifies the model as far as
the user is concerned though (nor the server admin for that matter since
providing this file at the right time is not trivial).
But maybe you have other options in mind that will benefit from that ?
If not, I'd rather try to provide means that will work for all smart
servers (where 'bazaar.conf' and 'locations.conf' were and *are* still
> We needed a way to configure a location that allowed remote
> configuration (so locations.conf and bazaar.conf were out),
The local 'locations.conf' and 'bazaar.conf' are indeed out, but the
remote ones could be used in the general case (launchpad is a special
It *is* reasonable for the 'stacked_on_location' to be controlled by the
server and forbid overriding by the user (and that's what we did with
BzrDirConfig and still do). On the other hand, while this is certainly
an option you shouldn't play with without understanding the fallouts, do
we really want to totally forbid say, fixing a bogus value ? There is,
after all, nothing stopping a user to set 'stacked_on_location' in a
> but that location could have no branch or repository (so
> branch.conf was out).
Yeah, but as said above, this is a special case for launchpad, as a
smart server admin I may well set a policy for how branches are stacked
in 'repository.conf' or a (not yet existing either) 'defaults.conf' file
in ~/.bazaar in the home directory of the user running the smart server
(whether this user is the one connecting to the server or a dedicated
one is up to the server admin to decide).
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. We may want to find a way to support providing a
single config section for a given path (à la LocationStack(location))
without requiring the server to redefine accesses to the file system, by
say, having a hook that can query a database (which is what launchpad
does in the end IIUC).
> But it would be possible to use it for branches, trees and
> repositories, too, since they all have control directories.
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.e. each config file has a clear definition with regard to setting
options for its associated object or providing default values for a set
In other words, 'tree.conf' > 'branch.conf' > 'repository.conf' >
'defaults.conf' > 'bazaar.conf'.
'control.conf' can find its place before 'defaults.conf' but it seems
more specific to launchpad use case than a natural fit.
> And I think that collecting all that configuration in one place
> would be a nice simplification.
I'm not sure about the simplification. When a shared repo is involved,
two 'control.conf' are involved too and that seems less clear than a
'repository.conf' and a 'branch.conf'.
I'd be interested by use cases that cannot be supported by having the
config files I mentioned above (which don't require a format change as
long as the options we add preserve the existing behavior when they are
Nothing is cast in stone as far as I'm concerned, I just wanted to
clarify what I had in mind here.
More information about the bazaar