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

[Monty Taylor]

John Arbash Meinel wrote:

> 
> Not that I know of. Just making a complete statement. I did see things
> like:
> 
> def foo:
>   spaced in 2 spaces
>   try:
>       and then four spaces here
>   ...

Oh right... I've been trying to get rid of all that. Must have missed some.

> 
> On thinking about this, it feels like ~/.bazaar/plugin-name.conf should
> take precedence over .bzr-plugin-name/default.conf
> 
> Because one may be provided to you by the commit overlord of your
> project, but you should be able to do things the way you want.

Yes. Absolutely agree.

> 
>>
>> 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'm not a big fan of committing meta-data (like plugin configuration)
> into a projects working files. I think a nicer way would be to get our
> "branch.conf" code done in such a way that settings can propagate. It
> certainly was part of the spec way-way-way back. And when we should use
> ~/.bazaar/locations.conf versus branch.conf, and how to determine
> settings that propagate versus ones that don't.

Me either. It makes for really weird situtaions where you might branch
something old, and since that time the global project commit location
changed, but that doesn't show up... But without a "server respository
config", some of these centralized-overlord types of things are just
crap to model. :)

> However, this may be a reasonable short-term solution. I just worry
> about bringing it into core and making it *the* solution.

Well, I'm fine with keeping it in my local code for now. I've got a
changes I wanted to submit to bzr-email that depend on this that I was
trying to avoid having to send in a copy of this... it's called laziness
solved by pushing to trunk.

I would actually really prefer that this was in .bzr

> What if we had 2 config files:
> 
> .bzr/branch/branch.conf
> and
> .bzr/branch/local.conf
> 
> So that 'branch.conf' would have its values propagated, and 'local.conf'
> would not.

I like that. I think the naming makes sense with the purpose, too.

> 
> Things like "parent" and "branch-nick" should then be moved into
> .bzr/branch/local.conf
> 
> We could, of course, use a different name than "branch.conf" for the one
> that propagates. I just could think of "local" but couldn't think of a
> good single small word which meant that these settings should be copied.
> 
> Of course, this also means we need to think about what should happen on
> "push/pull/merge", and how to handle mixed data. (eg, the local file has
> "foo" and "bar", but the remote has "bar" and "quux". What ends up in
> the final file? All three, just 2, etc. If all 3 how do you propagate
> deletes, etc.)

Yup. Back to the problem of how the versioning of this meta-data works,
and how it relates to the version graph. It's almost like it wants its
own special set of changes in the repository, so that any time a branch
is pulled, it'll always get all the special meta-changes - so even if
you did

bzr branch -r1 trunk old_version

You'd wind up pulling the most recent copy of the metadata?

Monty