[MERGE] Tree-specific rules

[Lukáš Lalinský]

On Mon, Jan 5, 2009 at 10:44 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> 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.

There are tags, which are also project specific but are stored in
branch. I think the main location of rules should be in branch. It
would be nicer to have them hidden inside the .bzr directory, but I
personally don't see a problem with storing it in a way git stores
.gitattributes (ie, any directory in the versioned tree). But that's
an old discussion, so let's not start it again. :)

> We shouldn't hold up having
> workable tree translation for early adopters because of the lack of part
> of the puzzle. The key question for me is 'do we want to *allow*
> per-tree configuration of rules' or 'prevent per-tree configuration of
> rules'?

I don't think this is the right question. There are two sides of the
working tree translation problem. On the project (branch in bzr, since
it's the closest object to project it has) side you need to specify
metadata about the tree, such as "files with extension .cpp and .h can
have native line endings", "files with extension .sh must have LF line
endings", "files with extension .html are encoded in UTF-8". And then
on the user side you can configure bazaar to filter the working tree
according to the rules set by the project maintainers, e.g. "convert
files that can have native line endings to CR LF", "recode files with
specified encoding to ISO-8859-2". I'd call the first part "rules" and
the second part "configuration". bzr already has global and
branch-level configuration, it already does have global rules. IMO,
what's missing are wt-level configuration and versioned branch-level
rules. This is what makes most sense to me, assuming I understood the
way rules are meant to be used correctly.

Lukas