[PREVIEW] line-endings support

[Ian Clatworthy]

Martin Pool wrote:
> I was thinking about this the other day, and it seems that most of the
> options being discussed have a lot of overlap with our existing
> configuration system, and it would be nice to have only one rather than
> two, all else being equal.

I think our configuration system really rocks. There's a heap of power
in there but we don't really use it or advertise it much.

> We already have a way to define settings that apply globally, per user,
> per branch, per location (either recursively or not).  So, how about
> adding a concept to the configuration system that you can ask it to look
> up settings for a particular path, and they can match either the full path
> or a glob.  As a straw man maybe in ~/.bazaar/bazaar.conf
> 
>   [glob:*.py]
>   eol = native
> 
> I think eventually having these rules propagate to people who get
> checkouts of the tree is important, indeed the main point of them is to
> get consistent results when several people with different setups are
> working on the same project.  So, whatever mechanism we use, it has to get
> into the branch, and be carried around when you push, pull, etc.
> 
> If we specify these things as globs rather than as per-file properties we
> avoid some scaling problems of having O(n) lists.  Even quite large trees
> are likely to have modest numbers of different rules.

Yes, that's my expectation as well.

> One straightforward way to put this into the branch is to have it
> controlled by a dot file in the tree, as Alexander has currently done.
> Having it in there does have shortcomings but it really is pretty nice to
> have conflicts and merges in the standard way.

That's certainly appealing. We do have metadata though that isn't
handled this way, e.g. tags. How are conflicts and merges handled for
them? Can that system be generalised to support configuration settings
and if so, is that a good idea?

> Another nice thing about doing this through configuration is that we can
> stepwise have it at first just global (at least as a prototype) and then
> make it more specific.
> 

Agreed.

Ian C.