On Fri, Oct 1, 2010 at 3:57 AM, Julian Foad <julian.foad_at_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.
Received on 2010-10-03 20:56:17 CEST