Rule-based preferences - format marker RFC, etc.

[Ian Clatworthy]

Ian Clatworthy wrote:
> Martin Pool wrote:
>> On 6/24/08, Ian Clatworthy <ian.clatworthy at internode.on.net> wrote:
>>> John Arbash Meinel wrote:

>> If we want new rule syntax then
>> perhaps we just need to make sure the syntax itself has room to grow.
>> For example if the section headers were
>>
>> [glob *.py]
>>
>> then we can add more in future, and potentially also check whether all
>> of them are understood by the current version.

poolie and I talked about this some more today. To allow room to grow,
we agree we should add a namespace to the front of sections as shown
above. The issues are:

1. What to do if we find a keyword we don't understand.
2. What keyword to use for patterns

In the initial cut, I want to error on unknown keywords. We can always
soften that in that future if there's a good case for doing so.

As far as selecting a keyword goes, I'm not keen on 'glob' because it
can also be a regular expression if it starts with RE:.
Some other alternatives are:

* preferences
* pattern
* when
* on
* if
* for
* name.

Some examples of how these would look:

  [on *.bat]
  eol=dos

  [name *.bat]
  eol=dos

If we wanted to support file-ids over and above filenames, we might
introduce a new keyword in the future like id. Or we could extend
the pattern language with an ID: prefix, e.g.

  [on ID:foo]
  eol=dos

  [id foo]
  eol=dos

More interestingly though, the namespace lets us add rules that
apply at the whole-of-tree level, e.g. [requirements],
[recommendations]. See below.

>> If people do want them then I'd
>> come back to having a way for the user to say "this tree should be
>> used with bzr version >= X, and with plugins Y and Z."  I suppose that
>> could be done either in the tree itself or in branch.conf.
> 
> Or we could drop the format marker idea and make these requirements a
> section of the rules file. For example:
> 
> [requires]
> bzr=1.6
> bzr-eol=0.1
> company-policy-plugin=2.1

We think this is a better direction that a format marker because
developers can be more explicit about what's required to work on a tree.
It doesn't need to land as part of this patch, but this patch needs
to permit this in the future by supporting a namespace now. See above.

So any votes for preferred keyword? My favorites are 'when' & 'on'.
poolie likes 'name' more than 'when' as the latter has associations
with time.

Any other thoughts on the above before I resubmit this patch?

Ian C.