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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4