branch specific rules - the latest proposal

[Alexander Belchenko]

Ian Clatworthy пишет:
> Alexander Belchenko wrote:
>> * 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.

I'm not sure right now. It depends on how internal API will work. So maybe:

xxx          # main form
xxx.local    # local settings

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

Yes, I'm talking about versioning of the format. Currently for scmproj I'm put 2 lines at the top of
project.cfg:

### project.cfg v1
### Don't edit the line above!

>> * 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, I have very specific question: I want to store metadata about versioned files (binary flag,
encoding of text). Such metadata should *not* belongs to some *one* plugin. I'm sure both qbzr and
bzr-gtk may want to use such metadata. So policy of using namespaces will be wrong there. That's why
I'm asking about standartization for *common* things. Plugin namespaces is good idea. But perhaps
there should be special namespace for some common/standard metadata. E.g. your "rules" file. Does it
belongs to "rules" plugin?