[Python-Dev] PEP 385: the eol-type issue

Nick Coghlan wrote:
> Mark Hammond wrote:>> On 5/08/2009 7:09 PM, Dirkjan Ochtman wrote:>>> I'm not sure how win32text will provide anything other than>>> performance degradation for non-Windows developers, but if there's>>> functionality to be had, I'm happy to mandate its use on every>>> platform.>> I see two practical outcomes of such a mandate:>>>> * line-ending rules are enforced for local checkins, even for linux>> users, even though such 'accidental' inappropriate line-ending checkins>> should be much rarer than for windows.>>>> * practical problems faced by Windows users, including any performance>> considerations, are shared by the community and therefore addressed as a>> community, thereby ensuring all platforms are considered as important as>> any other.> > The main error that enabling win32text everywhere can catch is the use> of a *nix client to accidentally corrupt one of the files that is> supposed to have \r\n line endings.> > It also simplifies the configuration rules in the Python hg FAQ - we> would be able to just tell all developers wanting to contribute patches> to Python to enable the win32text extension when working with the Python> repositories (or clones thereof) without having to worry about what> platform they were on.> > So it seems to me that the main client-side feature we want is a> versioned .hgeols file in the repository that allows files to be> explicitly nominated as one of:> - eol=CRLF (i.e. have \r\n line endings in the repository and should be> left that way on the local disk as well - equivalent to SVN eol-style:CRLF)> - eol=LF (i.e. have \n line endings in the repository and should be left> that way on the local disk as well - equivalent to SVN eol-style:LF)> - eol=CR (i.e. have \n line endings in the repository and should be left> that way on the local disk as well - equivalent to SVN eol-style:CR)> - native text (i.e. always stored in the repository with \n line> endings, but uses native line endings on the local disk - equivalent to> SVN eol-style:native)> - binary (i.e. always reproduced on disk exactly as they are in the> repository - equivalent to SVN files without eol-style set at all)> > The .hgeols file should also allow the repository to define which of the> above should be used as the default handling mechanism for text files> that are not named in the file (native text, in the specific case of the> Python repositories).> > Files which look like binary files (according to the existing win32text> heuristics) would be left alone regardless of what the default handling> was set to in .hgeols.> > win32text would then be enhanced to check for a .hgeols file before> falling back to its existing configuration mechanisms.> > The above basically provides the SVN eol-style feature in a more> hg-friendly way. Allowing wildcards in the .hgeols files might be nice,> but I don't think it is actually required. We really don't have that> many files that are affected by this problem (it's just the fact that it> is a number greater than zero that is causing the problem).> > The server side pre-push hooks for the main Python repositories would be> set to reject change sets which didn't meet the above rules. If a patch> fails those checks, either the committer can fix it themselves and> resubmit, or else send it back to the originator along with a pointer to> the section in the dev FAQ that describes the expected client-side> configuration.> 
Instead of just talking about line endings, could each file have a
specific 'filetype'? This would define what kind of data it contains,
how it's stored in the repository, and what actions to perform for
fetching and committing, including any checks:

     c_header: C header file; LF in repository; native outside

     c_source: C source file; LF in repository; native outside

     text: plain text; LF in repository; native outside

     crlf_text: plain text; CRLF in repository; CRLF outside

     cr_text: plain text; CR in repository; CR outside

     lf_text: plain text; LF in repository; LF outside

     binary: arbitrary binary data; as-is in repository

This could be expanded in the future to include filetypes for JPEG, etc.