Need a way to set content-filtering rules across a project

Frits Jalvingh jal at etc.to
Fri Nov 12 23:07:13 GMT 2010


Hi Alexander,

Thanks for your response.

I think having a beautiful version control system and then maintain this
kind of configuration outside it borders on the silly. But this is an
error made by lots of systems (Eclipse *cough*) time and time again, so
it appears to be an easy to fall for "solution"....

I do see some problems with approaching rules configuration as a
"versioned properties" problem- depending on what you define to /be/
versioned properties. In the current rules file definition there is an
order defined between rules; the rules do *not* stand by themselves. The
rules are defined to be matched by file name by traversing the rules
file from top to bottom, and using the first match for the property
sought.

This is flexible but it also means the entire file should be seen as a
single "property"- because individual lines depend on each other. If we
retain the current way of handling rules this means we need to have file
like versioned properties, and we need to do file-like merging. This
kind of feels like the idea Marius has stated in the bug.

I do not really like that as a solution, because having properties as
files is actually just a special case of having a set of .bzrmeta/xxxx
files representing them; that would then be best because we can mostly
use generic bzr to at least merge etc them. That might be quite easy to
implement, provided we can do merges ordering .bzrmeta as first, and
abort the rest if .bzrmeta merge fails. Handling administration for that
would be hard I think.

If we go the "versioned properties" route I think we need:
* versioned properties with specific classes, so that we can quickly
load all of them in a certain class.
* the class is also needed because code needs to trigger checks
depending on the class of the property being changed
* Rules properties that do NOT depend on order of entry. They can depend
on each other like having a property with a more restrictive path
overriding a property with a less-restrictive path (example: the
property "path-/WebContent/*.html=eol:crlf" is better than the property
"path-/*.html" for all html files below /WebContent.

The only thing I found regarding versioned properties is an old (2006)
spec at http://wiki.bazaar.canonical.com/VersionedProperties - is there
something newer? Is something being worked on?

If the versioned properties thing is controversial it might be best to
start with a simpler solution initially. I would propose like how tags
are maintained, as a serialized entity, for rules config only. We would
add an UI to maintain that, and we would need a better way of merging
than just overwriting..





More information about the bazaar mailing list