Daniel, sorry I haven't looked at this yet, and won't be able to today. - Julian
On Sun, 2010-10-03 at 11:55 -0700, 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.
