EOL extension

[Mark Hammond]

On 2/12/2009 9:50 AM, Paul Moore wrote:
> 2009/12/1 Mark Hammond<mhammond at skippinet.com.au>:
>> On 1/12/2009 11:25 PM, Dirkjan Ochtman wrote:
>>
>>> So, at this point, do you
>>> have *concrete* suggestions for the eol extension?
>>
>> Yes - please see my first message in this thread.
>
> IIUC, you're saying there that with Subversion, users set up a config
> file (locally) which, based on file extensions, marks files as "text"
> (using Subversion per-file properties). Text files are then always
> checked out with native EOL style.
>
> OK, with the EOL extension, the equivalent would be as follows:
>
> There's a *central* config file (better than Subversion, as it's part
> of the repo and so doesn't need to be manually set up) which marks
> files as "text" based on extension. The "marking", in this case, is
> not by means of properties attached to files, but by a direct
> statement that "native" EOL style should be used.
>
> This seems to me to be strictly better than Subversion, as the
> extension->text mapping is in the repo (and versioned) rather than
> being local. There's still local config required, but it's solely to
> enable the extension.
>
> If I've misunderstood, please can you clarify with a specific example
> - but it seems to me that the EOL extension as it stands does exactly
> what you want. (It certainly seems to do everything I'd want, but my
> experience of the possible pitfalls is far less than yours).

In that first response (which I am surprised managed to stretch to so 
many emails before being directly acknowledged) I was looking to avoid 
any configuration being necessary when a file with an 'unknown' 
extension is added.  This should prevent files being accidentally 
introduced with \r\n line endings, and potentially edited on non-windows 
platforms before someone notices and needs to make a "correction" 
checkin which appears to touch every line in the file.

To be quite honest, I'm not sure I have the energy to run this same 
gauntlet with every issue I come across, but hopefully that was just a 
bad start and I will be given the benefit of the doubt in the future for 
issues in which the core developers have no direct experience...

Cheers,

Mark