branch specific rules - the latest proposal

[Ian Clatworthy]

Alexander Belchenko wrote:

> * Does .bzrmeta will be final answer on the question: "will bzr support versioned properties"?

We have no plans for bzr core to ever support versioned properties.

> * How you suppose to fix chicken-eggs problem? E.g. on the phase of building/updating tree you need
> access to .bzrmeta content but it is not hit the disk yet?
> * If there is planned to provide some sort of builtin API to work with .bzrmeta content?

I'm pretty sure my earlier patches in this space ran into exactly that 
problem and the solution was a a smart API. My expectation is that that 
API will be useful to plugins. More details later after I think about it 
  more.

> Any CLI API
> planned to set/change/delete config options/rules?

Not at this stage.

> * For plugins like scmproj or bzr-externals there is need in having 2 forms of some config/rule:
> canonical form which stored in repo and local form which can be used to override some settings
> locally (e.g. if you have local mirror of heavy branch then you don't need to fetch it every time
> from internet). Local form never should be committed to repo. Will you provide some
> support/standardization on this?

I'm open to the idea, at least at the "standard policy" level. Let us 
know which policy works best for you.

> * When I wrote .checkeol plugin and .bzrprop implementation there was raised question/suggestion
> about versioning of the config control. Do you have any proposal on this? I saw several times
> regrets re .bzrignore and absence of versioning for it.

I assume you mean versioning of the format instead of versioning of the 
data, yes? There are many solutions including:

1. a format string on the top line.
2. a policy of maintaining upwards compatibility in combination with
    branch "requirements" saying "requires bzr >= x.y.z" once you start
    using features only supported in x.y.z.

I'm pretty sure poolie likes format strings in generated files but 
dislikes them in user editable files.

> * Do you plan to move .bzrignore into .bzrmeta?

Not in the short term.

> * If I want to store metadata about verisoned files (binary flag for some files, encoding of content
> for text files, etc) does there will be standard names/locations/rules? Does builtin algorithme will
> use these rules, e.g. will diff use binary flag to avoid diffing multimegabytes non-text files? Is
> it will be implemented on the level of CLI (builtins.py) or in core modules?

I think a reasonable policy is for a plugin called bzr-xxx to use the 
xxx namespace under .bzrmeta. In other words, it could use a single file 
  called xxx, a set of files called xxx-yyy or whatever makes sense to 
it under a .bzrmeta/xxx/ directory. Plugins can them split up their 
custo metadata based on what makes merging work best, e.g. a small text 
file with some settings and a larger binary file if that works. We'll 
probably need to add some hooks so plugins get better control over 
merging their stuff in there.

Ian C.