[MERGE] Added PluginBranchConfig object, which allows a generalized mechanism for setting config options which travel along with the branch.

Monty Taylor monty at inaugust.com
Mon Feb 4 20:09:08 GMT 2008


John Arbash Meinel wrote:

> 
> There are a few stylistic things that would need to be updated. For
> example, we always put 2 blank spaces between top-level entries
> (classes/functions/etc), and your docstrings need a small amount of
> cleanup. They should generally start with a single sentence, which fits
> on a single line without wrapping. And we usually put the trailing """
> on a line by itself. Also, we always indent 4 spaces, no tabs.

No problem. Did I really have tabs in there? Sick!


> 
> 
> The way these are listed is a bit confusing. As I'm pretty sure
> "locations.conf" is talking about ~/.bazaar/locations.conf, and I would
> guess "bazaar.conf" is as well, but you explicitly enumerate
> ~/.bazaar/plugin-name.conf
> 
> So I would probably say:
> 
>   ~/.bazaar/locations.conf
>   .bzr-<plugin-name>/default.conf
>   .bzr/branch/branch.conf
>   ~/.bazaar/bazaar.conf
>   ~/.bazaar/<plugin-name>.conf

Agreed.

> I also find the ordering a bit weird. I know we usually put
> "locations.conf" before a specific branch.conf so that users can
> override upstreams settings on their local machine. (When I access
> http://bazaar-vcs.org/bzr/bzr.dev, I should have the right to say how it
> should act on *my* machine.)
> 
> However, I don't really see why the global ~/.bazaar/bazaar.conf would
> override the plugin-specific ~/.bazaar/plugin-name.conf

Agreed.

> I don't really like having ".bzr-plugin-name/default.conf". Something
> more like ".bzr/plugins/plugin-name.conf" I think is a better layout.
> Unless the goal is to actually version the defaults. Which is a
> possibility. We should take care when advocating it. One of the reason
> we generally *don't* is for security purposes. As we don't want merging
> an unknown branch to start automatically spawning processes that you
> might not want.
> 
> Certainly you wouldn't want "bzr log http://other/branch" to allow
> spawning an arbitrary command on your local machine. Your changes may
> not introduce it, but we should keep it in mind.

I agree... I don't want random stuff in branches executing code. This
should not happen with this code, but you are right, we do need to keep
that in mind.

The problem with putting it in .bzr/plugins is that it doesn't travel
with the branch (as far as I can figure out) Let me give an example of
the problem... maybe there's a better way to solve it.

Say I've got a branch somewhere, http://foo.net/bzr-plugins/trunk and
another at http://foo.net/bzr-plugins/trunk-special. I want commit
messages for trunk to go to commits at foo.net, and I want them to carry a
tag "trunk". I want commit messages for trunk-special to go to
commits at foo.net, and I want them to carry a tag "special". When someone
branches it, I want those commit messages to also go to commits at foo.net
and carry that tag (which in this case is an indication of something
more like a release series)

I don't want each developer to have to set this up (consider that there
are 150 or so developers) when they branch things. A repository location
based post_commit_to wouldn't be so terrible, but in my case I have 30
or so active "release series" that could be branched from and for which
commit messages want to be sorted, so I really don't want that many
local configs people are setting up.  But I also don't want to have this
setup send commit messages for a branch of bzr.dev to commits at foo.net

So the way this would work is:

plugin bzr-foo that provides post_commit_hook to send the messages I want.

In ~/.bazaar/bazaar.conf:

allow_remote_options = foo

Which turns on the ability of the foo plugin to use per-branch config
information at all.

In trunk/.bzr-foo/default.conf

post_commit_to = commits at foo.net
tree_name = trunk

Then, since that's checked in, I merge it down to trunk-special, and
then in trunk-special, change

tree_name = special

Other than setting up the global trust of the foo plugin, the individual
dev doesn't have to do any individual per-branch configuration.


I had considered getting rid of .bzr-<plugin-name> and replacing that
with .bzr-plugins with different files or different config sections inside.

Whether it sounds desirable or not - have I at least described what I'm
trying to achieve here?

> As for writing unit tests, this is showing up in "bzrlib/config.py" so
> you should add some tests in "bzrlib/tests/test_config.py"

Ok. Will do.

> Make sure that you can get options out of files in the appropriate
> places, that if you set a value, it updates the "correct" file, etc.
> 
> Which brings up another point, you have a lot of "get_*" functions, but
> no "set_*" functions. Our BranchConfig and GlobalConfig both provide
> ways to have the program set values, which seems like something you
> would want here. So we would want to define where settings go, and how
> to get them to go elsewhere.

I thought about that... I'm not 100% sure what commands or tools would
use those - but you're right, they should probably be ther nonetheless.

Monty



More information about the bazaar mailing list