> Can anyone (re-) post the specification of the proposed extension, to > the level that it is currently defined?
For reference, here are the original specification, mine and Martin Geisler's: http://mail.python.org/pipermail/python-dev/2009-August/090984.html http://mail.python.org/pipermail/python-dev/2009-August/091453.html Here is my attempt at summarizing it: - name of versioned configuration file (in root of tree): .hgeol - names of conversion modes: native, LF, CRLF In the configuration file, there is a section [patterns] which maps file name patterns to conversion modes, e.g. [patterns] **.txt = native **.py = native **.dsp = CRLF **.bat = CRLF Tools/bgen/README = native Lib/email/test/data/msg_26.txt = CRLF - Martin Geisler also proposes that there is a section [repository] native = <conversionmode> I personally feel YAGNI; it should only support LF (adding such a feature later may be considered) Open issues: - name of extension - what should happen if the file on disk doesn't have the "expected" line endings, or mixed line endings? E.g. a file declared as native "should" have CRLF on Windows - what if it doesn't, on commit? My proposal: do what svn does (whatever that is). That's it, AFAICT. Martin Geisler also discussed something that I read as an implementation strategy, by mapping the patterns to into the (apparently existing) encode/decode configuration setting. HTH, Martin P.S. If you decide that you will or will not work on it, please let us know. _______________________________________________ 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