[PREVIEW] line-endings support

[Martin Pool]

On Thu, Apr 17, 2008 at 12:17 AM, Aaron Bentley <aaron at aaronbentley.com> wrote:
> Martin Pool wrote:
>  > If we specify these things as globs rather than as per-file properties we
>  > avoid some scaling problems of having O(n) lists.
>
>  If the properties are stored with the files (e.g. as part of the
>  inventory entry), we have no (new) scaling problems.
>
>  > Even quite large trees
>  > are likely to have modest numbers of different rules.
>
>  Large trees are likely to have exceptions to their rules, however.

I'm starting from the observation that generally these things are not
set one-by-one for each existing files, but generally there are rules
applying to particular file types.  You're right that there may be
exceptions of various types, but the exceptions are just more rules
(and a requirement that the rule system be sufficiently flexible.)  I
still maintain that the number of different rules is likely to be much
less than the number of files.

Therefore I don't think it's a good match to treat these just as
properties that are stored on particular files:

It means taking a small set, and redundantly storing it as a larger
set.  Even if it's only O(nfiles) and we already have to do O(nfiles)
operations, we're still increasing the constant factor.

I'm not sure it gives a good user experience: people want to define
the rules and have them stay set; this is a source of complaints about
Subversion properties.

>  > 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.
>
>  There are some problems with this.
>
>  It introduces a fourth location where configuration data may be stored.
>  This will cause further confusion.

I think your other points are very good, but as far as the number of
locations, I think we need as many as necessary but no more.  It seems
there has to be some way to put control data in the tree.  Making that
part of the config system is not, in itself, more confusing than
having it separate: a choice of one namespace controlled in four
places, vs two namespaces also controlled in four total places.

>  Many config values are not suited for propagation like this.  Since
>  merges will propagate these values, only settings that are true in all
>  branches that will merge this one should be stored here.

Good point.

I think for some of these, like the submit address, signature
settings, and some location configs, there is a need for a project
(larger than a single branch) to set up standards.  Projects using
Bazaar typically instruct their users to do particular things, some of
them would be amenable to automatically setting configurations.  But
these might not want to propagate with regular branch merges, they're
at a different kind of level from per-file settings, and it's probably
not an urgent problem.

-- 
Martin <http://launchpad.net/~mbp/>