From ed7e0cc37c7a3f451092783a8f68c5773a4c32e4 Mon Sep 17 00:00:00 2001 From: "Jason R. Coombs" Date: Sat, 23 Nov 2013 17:45:01 -0500 Subject: [PATCH] Update changelog. Fixes #105 and Fixes #113. --HG-- extra : amend_source : 10cadb252bc504ef25c9f9cf7f3cdc5bf03fd367 --- CHANGES.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/CHANGES.txt b/CHANGES.txt index 9190aee290..b20d16839c 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -9,6 +9,29 @@ CHANGES * Issue #114: Use ``sys.getfilesystemencoding`` for decoding config in ``bdist_wininst`` distributions. +* Issue #105 and Issue #113: Establish a more robust technique for + determining the terminal encoding:: + + 1. Try ``getpreferredencoding`` + 2. If that returns US_ASCII or None, try the encoding from + ``getdefaultlocale``. If that encoding was a "fallback" because Python + could not figure it out from the environment or OS, encoding remains + unresolved. + 3. If the encoding is resolved, then make sure Python actually implements + the encoding. + 4. On the event of an error or unknown codec, revert to fallbacks + (UTF-8 on Darwin, ASCII on everything else). + 5. On the encoding is 'mac-roman' on Darwin, use UTF-8 as 'mac-roman' was + a bug on older Python releases. + + On a side note, it would seem that the encoding only matters for when SVN + does not yet support ``--xml`` and when getting repository and svn version + numbers. The ``--xml`` technique should yield UTF-8 according to some + messages on the SVN mailing lists. So if the version numbers are always + 7-bit ASCII clean, it may be best to only support the file parsing methods + for legacy SVN releases and support for SVN without the subprocess command + would simple go away as support for the older SVNs does. + --- 1.4 ---