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.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.
> <log message.txt><patch.txt>
Received on 2010-10-18 12:07:17 CEST