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.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-07 16:30:50 CEST