branch specific rules - the latest proposal

[Ian Clatworthy]

Alexander Belchenko wrote:

> I'm not sure right now. It depends on how internal API will work. So maybe:
> 
> xxx          # main form
> xxx.local    # local settings

Sounds ok to me. Depending on the complexity of the local metadata,
another option is to use settings in branch.conf (like bzr-pipeline does
for example).

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

Cute.

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

That's a very good point. I certainly expect to put stuff in there that
isn't in the namespace of one plugin. Socially though, we want to use
that namespace wisely. If you'd like to use a name outside the namespace
of a plugin, please ask on the mailing list first.

To clarify my statement about versioned properties, you could write a
"properties" plugin that added them. Other plugins could then depend on
that plugin. In the case of bzr-svn in particular, that's one perfectly
acceptable way of achieving a lossless round-trip.

Right now, our expectation is that rules scale better than per-file
properties. That doesn't make rules the right answer for everything but
it does mean we'll strongly encourage plugins to use rules if they can.

I can't overstate how pleased *I* am with the outcome from last week's
sprint. We've opened acknowledged some bottlenecks and put in place
better policies to deal with them. These include:

1. Patch pilots to help contributors get changes into the core.
2. An official policy (at last) for in-tree metadata storage (.bzrmeta).
3. Approval "in principle" to add branch dependencies, giving projects
   an increase in safety if they rely on hooks/plugins and reducing
   some of the pressure for formats bumps.

Collectively, that's a large social change that will hopefully empower
the Bazaar community more than ever before.

Ian C.