[Python-Dev] Mercurial migration: progress report (PEP 385)

[Mark Hammond]

On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
> On Fri, Jul 3, 2009 at 15:31, Mark Hammond<mhammond at skippinet.com.au>  wrote:
>> So we must work without effective EOL support?  I fear we will end up like
>> the mozilla hg repo with some files in windows line endings and some with
>> linux.  While my editing tools are good enough to preserve existing EOL
>> styles, I've found myself accidentally checking in new \r\n terminated files
>> in a repo which otherwise uses \n line endings.  IMO, SVN's EOL support was
>> better than no EOL support.
>
> This is why we'll have hooks -- to prevent you from pushing changesets
> with inappropriate, to say the least, and, if you're willing to do a
> little bit of extra work, to prevent you from committing them.
>
>> This is exactly why I was asking for your advice - I can't work out how to
>> work effectively with win32text as it stands myself, so remain stuck
>> accidently checking in files with inappropriate line endings and stuck
>> working out how to move pywin32's CVS repo with abandoning the very
>> primitive EOL safety it offers...
>
> As long as the difference between \r\n- and \n-based files is clear
> and can be reasoned about, I don't see why having some of both (I'm
> assuming an overwhelming majority will have one, and only a few the
> other) is a big problem. But feel free to enlighten me!

I'm surprised it isn't obvious.  Think about it this way: CVS had basic 
EOL support and SVN gave slightly better support, and we leveraged this 
support in both those tools.  The end result is a very clean repo with 
consistent line endings and a distinct lack of developer friction 
between the platforms.

Your position seems to be that we *never* needed EOL conversion, 
especially in SVN which offered decent hooks, and that having a source 
repo with a mismatch and unpredictable line endings isn't really a 
problem at all.

Even just at face value, it seems clear we have taken full advantage of 
that feature for around 1.5 decades, so to suggest we never actually 
needed it, or at least don't need it now for some reason, seems slightly 
disingenuous...

Cheers,

Mark