branch specific rules - the latest proposal

[Alexander Belchenko]

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, it's possible to use branch.conf, but it's much harder to edit it.

In first version of scmproj I've put local settings in loval.cfg near main project.cfg. Then I've
decided to move local settings to branch.conf, and current version of scmproj uses branch.conf.
It's not very convenient if you need to edit this settings manually often. And there is no CLI to
change config settings, although I saw unfinished plugin for this on LP.

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

I'm sure it's not the best way, and it does not prevent deleting it by mistake.
(Sigh)

>> 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 agree about rules in general. But.

As you know: "devil in details".

I need the way to set encodings/binary flag programmatically. Does rules already have required API
to set new values?

When I want to set encoding settings for file foo.c which already has manually added rule for
line-endings:

[name *.c]
eol = native

How my "encoding = cp1251" will be added then? As:

[name *.c]
eol = native
encoding = cp1251

or as:

[name *.c]
eol = native

[name foo.c]
encoding = cp1251

In the latter case, does for foo.c still be applicable eol settings?

Am I missing something obvious? Or it should be in the end:

[name *.c]
eol = native

[name foo.c]
eol = native
encoding = cp1251

In this case: does eol setting will be propagated automatically, or programmer should copy all
settings from pattern to specific file himself?

So when you try to put rules as the one answer on all questions I'd like to understand how I can use
them from QBzr programmatically.

Sorry Ian, for my skeptical tone, but there is big holes in rules concept right now, at least for
me. So I hope decision to place them in the tree as .bzrmeta/rules will finally help to improve them
to be more useful for people who need more than eol support.