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


Yeah. I would just point out that we *just* had someone show up on IRC 
and ask why he was getting ".bzr-builddeb/default.conf" in his .diff.gz 
files. It isn't a project file, but it is being versioned as one.

Also, you end up with some bad mojo when you merge between branches. 
Because now your meta-data file conflicts. That will be a problem with 
any system that tracks and merges meta-data, though.

In CVS it caused all sorts of problems with the $Id$ tags. I guess SVN 
does it a bit differently by squashing them back to $Id$ at commit time. 
Which at least helps merge. (Though I guess you get weird results with 
"svn co" giving different values for some files than "svn up", etc.)


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

There was a proposal a while back that would introduce a set of meta 
revisions. Which would hold stuff like tag names, etc. That would 
certainly be somewhere you could put information like this.

Another thing you might consider. What about having a plugin which just 
provides your site-specific configuration. So users have to accept that 
plugin, and then whenever Bazaar runs it will go out and try to make 
sure everything is configured correctly. Whether that is pulling in new 
plugins, or updating existing ones, updating config files, etc.

Just a thought. It would be a bit more coding on your part, but it might 
make for a smooth experience for your developers.

John
=:->