WorkingTree.wt.get_config_stack and BzrDirConfig
aaron at aaronbentley.com
Mon Feb 6 17:26:46 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 12-02-06 05:14 AM, Vincent Ladeuil wrote:
>>>>>> Aaron Bentley <aaron at aaronbentley.com> writes:
>> 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 value.
child_submit_to was also supposed to provide a default. The
repository no-working-trees file has a similar configuration effect.
> Moreover it really only fits launchpad use case
I think it's considerably broader than that. It fits any code hosting
service. We tried to provide the functionality as something that
would be useful for any situation where people wanted to use stacking.
It can replace branch.conf. It can replace repositories'
> , 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
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.
$ hitchhiker bzr+ssh://bazaar.launchpad.net/~abentley/juju cat
default_stack_on = /+branch-id/348938
I have never created a bzrdir related to juju. It is effectively a
static file present for any project. Although we don't provide a way
for users to create bare bzrdirs, they can create an empty branch to
get this effect.
$ bzr init control
Created a standalone tree (format: 2a)
$ echo "default_stack_on = /+branch-id/8633" > control/.bzr/control.conf
$ bzr init control/test
Using default stacking branch /+branch-id/8633 at
bzr: ERROR: Not a branch: "/+branch-id/8633/".
> That being said, I'm not against providing support for launchpad
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.
> 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)
I didn't intend for there to be a fallback from the branch config to
the (optional) containing bzrdir's control.conf, and without that,
your proposed change of default_stack_on would not work.
> I don't think generalizing 'control.conf' simplifies the model as
> far as the user is concerned though
I strongly feel that having one way of configuring a location is
simpler than having four ways of configuring a location.
> (nor the server admin for that matter since providing this file at
> the right time is not trivial).
I think that providing the file at the right time is trivial. If you
need to provide a stacking default, then you just create a static file
before creating any branches. If you need to configure the branch or
working tree, you do that after the branch has been created.
> 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 used).
I'm suggesting that it's better to use than creating a new working
tree configuration file. Those do not already exist, so there is no
compatibility concern there. It's true that using it for branches and
repositories may require a format bump.
> 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 case).
There is no remote file that controls a location. The only remote one
available controls the branch at a location. I don't see how
Launchpad is a special case, unless you mean code hosting in general.
> 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).
I disagree. We should allow the user to override, and we do. The
default is merely a suggestion.
> 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 ?
No, and I don't think I suggested that.
> There is, after all, nothing stopping a user to set
> 'stacked_on_location' in a remote 'branch.conf'.
And I fully support that.
>> 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
No, it's not. You can say it's a special case for privacy-sensitive
code hosting if you like.
> , 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
The user should be in control. The client, not the server, should
decide whether to follow the default config. The control files should
be visible to the user before they start creating the branch. To
support dumb transports, they should therefore be traversable from the
location where the user wants to create the branch.
> 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).
How would the user see the defaults, and how would they apply to
selecting a stacking location? How would this work for dumb transports?
> 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
> 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
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.
If you can mingle tree, branch and repository configuration in
defaults.conf, it will be confusing that you can't mingle them in the
> In other words, 'tree.conf' > 'branch.conf' > 'repository.conf' >
> 'defaults.conf' > 'bazaar.conf'.
Not having to remember a heirarchy of file types is one of the
> 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 not set).
I didn't mean to suggest that using control.conf would make new
functionality possible. I meant to suggest that it would make
configuring Bazaar simpler.
However, if there was no hard division between branch and control
directory options, it would mean default_stack_on and could be
specified in locations.conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the bazaar