Ping. This patch submission has received no comments. Gavin "Beau" Baumanis
On 04/10/2010, at 5:55 AM, Daniel Trebbien wrote: > On Fri, Oct 1, 2010 at 3:57 AM, Julian Foad <julian.f...@wandisco.com> wrote: >>> Adds a public API function, svn_subst_translate_string2(), an extension of >>> svn_subst_translate_string(), that has two, additional output parameters for >>> determining whether re-encoding and/or line ending translation were >>> performed. >> >> If we're going to add this functionality to _translate_string(), >> shouldn't we also add it to the other variants - _detranslate_string, >> _translate_cstring2, _stream_translated, _copy_and_translate4? >> >> I see you're adding the infrastructure into the (new) bodies of >> _translate_cstring2 and _stream_translated, just not (yey) exposing it >> in their APIs. >> >> I'm not sure. The set of 'translation' functions is already messy and >> it's not clear to me how useful this new functionality will be. > > I originally began working on svn_subst_translate_string2() because I > could not find a combination of public API functions that would allow > me to determine whether the line endings changed when a string was > both re-encoded to UTF-8 and normalized to LF line endings. The most > applicable, svn_subst_translate_string(), performs both translations > without indicating whether it re-encoded the string or normalized a > line ending. > > An alternative to extending svn_subst_translate_string() is to add a > public API function that does the re-encoding and another that > normalizes line endings. I think, however, that extending > svn_subst_translate_string() is better because though the current > implementation of svn_subst_translate_string() re-encodes, then > normalizes line endings, the single API function allows for the > possibility of a future improvement in efficiency as a result of > performing both translations simultaneously. > > > > Attached are a revised patch and log message. > <log message.txt><patch.txt>
