[RFC] A configurable scheme+location for custom rules

[Alexander Belchenko]

Ian Clatworthy пишет:
> As discussed in response to my tree-specific rules patch,
> Bazaar currently supports rules configured per user in
> BZR_HOME/rules. That's great in that it lets users
> define some global defaults they like but it isn't
> going to be enough. At a minimum, different projects
> will have different rules and share them across their
> development team.

I see this topic as never-ending story. Can we get some simple solution
before 1.12 will be released? I'll be OK with .bzr/checkout/rules
file at least, so we can start using it in QBzr per example.

> Thinking more broadly, it would be nice if we supported
> rules specific to:
> 
> 1. a tree
> 2. a branch
> 3. a project
> 4. a user

It's *too* much for me. I think only rules for particular branch/project matters.
But if we speaking about lightweight checkouts (which I'm using often enough)
then we should support and tree as well, because branch settings there is
not applicable.

> More importantly, it must be easy to *share* rules across
> any of the above. In some cases, it might make sense to share
> rules across semi-related projects, e.g. a bunch of bzr
> plugins.

I don't see there problem in either make hard or symbolic link for all
the people around using Linux. Windows people know how to copy files around.

> There are other desires too. Some users feel rules ought
> to be strictly treated as configuration while other's
> what to keep them versioned. Tools like bzr-svn and bzr-git
> may wish to dynamically map rules to the matching concept
> in the foreign system, making the .bzrrules approach
> an interfacing burden.
> 
> Speaking to poolie about this topic today, I'd like to
> propose a more flexible solution than my tree-specific
> rules offered. Here it is.
> 
> We support a new configuration setting called rules_location.
> The value of this setting has the format:
> 
>   [scheme::]path_or_url

What will be default value for this settings?
Without default nothing will works at all.
Can you support .bzr/checkout/rules as default?
Or may be .bzr/rules -- directly in the metadir.
This will collapse difference between lightweight and fullweight
branches, and even branches without checkouts.

Why not? Why?

> Initially, the only supported scheme is "bzr", i.e. the
> rules are to be parsed in Bazaar's (ini-file) format.
> The path is relative to the working tree root but a URL
> can be given if you want.
> 
> The setting can be defined in branch.conf, locations.conf
> or bazaar.conf with earlier locations taking priority.
> This implies that there are only two levels of rules for
> a given tree/branch: the custom one and the per user one.
> That greatly reduces the complexity vs combining rules
> across potentially 3 or 4 levels.
> 
> Here are some examples of how I expect different user
> needs being satisfied by this solution:
> 
> * Fred has the common setup of a bunch of branches inside
>   a shared repo for a project. He adds the following
>   setting to location.conf:
> 
>     rules_location = ../projectX-rules.conf
> 
> * Mary's co-located development team store their rules
>   in a central location, e.g. on a fast http server.
>   The history of the rules are tracked in a separate
>   bzr branch. Developers are required to configure
>   rules location is either bazaar.conf or locations.conf
>   with a value something like:
> 
>     rules_location = http://myserver/foo-rules.conf
> 
> * Bill wants keywords expanded in a selected tree/branch.
>   He adds a setting to branch.conf. (If and when we support
>   a tree.conf file, he can use that.)
> 
> * Chloe wants to share rules across a bunch of small
>   projects managed by plain bzr branches. She adds a
>   setting like
> 
>     rules_location = ../plugins-rules.conf
> 
>   to each branch.conf.
> 
> * Alex really wants to store his rules in his working tree.
>   He adds "rules_location = .bzrrules" to branch.conf and
>   adds ".bzrrules" to his ".bzrignore" file.

(Alex really want to have the versioned properties, but this does
not matter).

> I'm convinced I can't make everyone happy with any solution
> I propose so I'm aiming for "no-one violently objects" :-)
> 
> Thoughts?

Anything is good than nothing at all.
Default matters. Please, make default pointing to somewhere inside .bzr
and document this, so we can actually start using this rules.

Please!