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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com