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

[Mark Hammond]

On 4/07/2009 12:04 AM, Nick Coghlan wrote:

> However, I expect that would still be painful to work with for Windows
> developers, even if it prevented any line ending problems from making
> their way into the main repository. I believe that is where the
> win32text extensions can help. Looking at the Wiki page for win32text
> [1], I believe it would be a matter of configuring the extension to
> encode and decode all files with the extensions:
>
> *.py
> *.pyw
> *.h
> *.c
> *.in
> *.rst
> *.asdl
>
> That said, I don't see a way to tell win32text to also translate files
> which don't have an extension at all (e.g. NEWS or ACKS), and there
> doesn't seem to be a way to tell it to *skip* files matching certain
> patterns (if there was, we could just tell it to ignore extensions like
> .bat, .sln, .vcproj, .vsprops, .dps, .dsw, .wse, .ico, .bmp and convert
> everything else)

The big problem I have with win32text is that the rules are not 
versioned, meaning we will rely on every (windows only?) developer 
manually enabling the win32text extension, then manually adding these 
rules to an unversioned hgrc file.  Should the rules change over time, 
we will need to communicate that to every developer.  Contrast this 
with, say, SVN, where the rule is a versioned property on the file.

Further, if a repo *already* has mixed line endings and the file doesn't 
appear in the rules, win32text makes *lots* of noise regarding existing 
line endings and to "review your rules before you commit."  In effect, 
it seems to me that win32text will only work effectively if *all* 
developers using a repo are using it, or none are, or other steps have 
been put in place to ensure \r\n line endings in the repo are otherwise 
impossible.  I've completely failed to use win32text on the mozilla hg 
repo for exactly this reason.

Cheers,

Mark