Line ending translation extension

[Paul Moore]

2009/9/7 Dirkjan Ochtman <dirkjan at ochtman.nl>:
> On Mon, Sep 7, 2009 at 14:13, Douglas Philips<dgou at mac.com> wrote:
>> In a DVCS, policy decisions (such a line endings) can only be enforced
>> by hooks running on the repos wishing to enforce those policy
>> decisions. Anyone who can clone your repo, can make changes: with
>> funky line ending mixings, funky mixed character encodings, tabs and
>> spaces, whatever they want. That is the point of a DVCS. It seems that
>> what you want is to have a set of hooks on your "we care about these"
>> repos that will reject any changesets that violate your style. As an
>> example, NetBeans has a number of hooks to enforce their requirements:
>> http://wiki.netbeans.org/HgHowTos#section-HgHowTos-ServerHooksAbortPretxnchangegroup.somethingHookFailed
>> (or: http://bit.ly/bA3d0)
>>
>> You can even suggest that folks who clone your repo(s) set up commit
>> hooks for their local repos, so as to catch the same issues that your
>> shared repos will catch. This way when they try commit locally they'll
>> be warned/prohibited and can fix their stylistic violations sooner
>> rather than later.
>
> Yeah, I've made that point a zillion times, but apparently that just
> won't do for the python-dev community.

I think the point here is that the Python community is used to working
(with assistance from the svn EOL handling) in such a way that all
users get to work with their own tools without *needing* to fix their
differences from the repo-mandated EOL policy.

Because, conventionally, central repositories use \n line endings,
which match Unix conventions, this helps Windows users much more than
Unix users - and conversely, the "alert to EOL style violations"
approach hurts Windows users more than Unix users.

As an experiment, convert a repository you use regularly to have \r\n
line endings in the repositiory. Then add a hook that rejects commits
which don't stick to \r\n line endings. Now use that repository (I
assume you're on Unix) for a while, and in particular, make sure you
do some real work involving adding new files. Ideally, do some of this
under time pressure, just like you might in a release. See how it
feels.

Please note - this is NOT rhetoric. I don't personally know how this
feels, as even though I'm a Windows user, I'm not a committer on any
project that uses Mercurial and uses LF-based sources. (Ironically, I
have a project of my own, http://bitbucket.org/pmoore/ppeg/ and guess
what - without knowing or meaning to, I've got CRLF line endings
throughout, because that's what my tools produce!)

Paul.