[MERGE] Tree-specific rules

[Robert Collins]

On Mon, 2009-01-05 at 11:36 +0100, Lukáš Lalinský wrote:
> On Mon, Jan 5, 2009 at 5:40 AM, Ian Clatworthy
> <ian.clatworthy at internode.on.net> wrote:
> > lifeless, fullermd and I discussed tree-specific rules on
> > IRC today and agreed there was value in supporting them Real
> > Soon Now. Ultimately, we'd like to be able to define rules
> > that apply at a 'project' and/or branch level, perhaps by
> > embedding rules in locations.conf and branch.conf. That's
> > quite a complex change though, requiring further debate
> > (e.g. are nested sections in ini-files too ugly a syntax?)
> > and probably a branch format bump. There are also complexities
> > around reapplying rules from different branches against
> > a lightweight checkout.
> 
> 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.

Rules are essentially a superset of the ignore functionality, in that
they provide user specified logic to the tree about how to handle paths
that are present in the tree.

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

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

If we want to prevent it, then this is harmful, otherwise its beneficial
even if it is now the whole story.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090106/a23ed93d/attachment.pgp