[MERGE] Tree-specific rules

[Ian Clatworthy]

Robert Collins wrote:
> On Mon, 2009-01-05 at 11:36 +0100, Lukáš Lalinský wrote:
>> On Mon, Jan 5, 2009 at 5:40 AM, Ian Clatworthy

>> This makes me wonder what are "rules" meant to be useful for. I was
>> expecting them to be a solution for defining some extra metadata about
>> versioned files, like text encoding, line endings, keyword expansion
>> behavior.

That's right. I'm sure teams will find many uses and they will prove
a useful way for plugins to define tree-related metadata.

>>  I don't know if I'm the only one, but I find it unreasonable
>> to expect users to manually edit .bzr/checkout/rules every time they
>> make a new branch. Things like keyword expansion are a
>> project/branch-level decision, not something every user of the branch
>> should set manually (e.g., the build process might depend on having it
>> defined in a specific way).
> 
> Certainly the tree specific rules are not the full set of functionality
> that is needed. However they are useful in their own right :- going back
> to CVS days it was common for build farms and individual developers to
> have different settings for keyword expansion. As for manually editing
> the tree rules on every new branch - how is that in *any* way different
> to manually editing branch specific rules every time you make a new
> branch?

For developers working on just a single project, there's always the
global rules file, BZR_HOME/rules. Right now, that's in fact the *only*
option - something this patch improves (without solving the bigger
problem of project-specific rules).

> As you say the settings for what to do when pulling content onto disk
> are largely a project decision, and we have no consistent answer for
> project configuration at the moment.

And the best answer currently available, locations.conf, doesn't meet
most people's requirements here either. After all, the "project
configuration" settings in there don't propagate with the project,
get versioned, get merged, etc.

My initial solution to the problem was having a .bzrrules file in
the working tree but this caused problems with bzr-svn as is broke
our design goal of keeping metadata out of the main tree. Robert
has offered to work on a better, longer-term solution but that will
take time and isn't his top priority right now.

In the meantime, this patch lets developers have tree-specific rules
(which beats trying to make the global file work for every project).
Projects using these will certainly need more setup doc, e.g.

  1. bzr branch ...
  2. download file X and save it as .bzr/checkout/rules
  3. make sure you install plugins A, B and C (e.g. eol, keywords,
     etc.)

Propagation across branches remains annoying. I wonder if hooks
and/or a simple plugin have potential as a solution to that?

In summary, the patch is (IMO) a step forward we can land in days
rather than the full solution which is (I feel) most likely months
away still.

Ian C.