[PREVIEW] line-endings support

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On Thu, Apr 17, 2008 at 12:17 AM, Aaron Bentley <aaron at aaronbentley.com> wrote:
>>  > 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.

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

This argument I can agree with.

Doing it based on rules means that they're dependent on filename, which
means that renames can change a file's EOL behavior.  I don't see that
as a good thing.  Maybe it would be okay if there was a warning about
the change in behavior when commit or status was invoked.

Maybe you feel that's an acceptable compromise to reduce redundancy, but
it definitely is a compromise.

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

Does Subversion have rules for what happens to newly-added files?

I think that it would be good to have a system in which files have their
EOL behavior set according to rules when they are initially added.  From
then on, the EOL behavior would be associated with their file-id, and
never changed except through user interaction.

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

I disagree.  I think that one namespace controlled in 3 places and
another controlled in one is a simpler mental model.  If I am trying to
find out why a value is set as it is, it is simpler to trace through
three locations than four.  It is also simpler to remember the
precedence of three locations rather than four.

This does require the user to associate EOL rules with their working
tree, rather than with other config values.  But this is something we
already ask them to do with .bzrignore files, and that seems to work well.

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

Full ACK.

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

And it's also a problem that can be dealt with piecemeal.

Anyhow, as I've said, I never expect to use this, so I don't have a big
investment in the particulars.  Using patterns may well be a good 95%
solution.  The main thing is that I don't want branch configuration
values stored as versioned values in the working tree.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIBszb0F+nu1YWqI0RAlWNAJ9O+2r7RHjztdfE45JwyD1ygPko3QCfVGjh
aLuhb7bvWKvabOLYuMgsezw=
=ALb2
-----END PGP SIGNATURE-----