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

[John Arbash Meinel]

Monty Taylor wrote:
> 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!
> 

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
   ...

> 
>>
>> 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.

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.

> 
...

> 
> 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.

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

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.


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.)

> 
> 
> 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
> 

Well, it is just a matter of a plugin providing commands to configure 
itself. In general, if there is something you want to get out of 
.bzr-plugin.conf then you probably want a way to set it.

John
=:->