[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: In svn_subst_translate_string(), shouldn't REPAIR in the call to svn_subst_translate_cstring2() be TRUE?

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 14 Sep 2010 09:33:32 +0200

> -----Original Message-----
> From: Daniel Trebbien [mailto:dtrebbien_at_gmail.com]
> Sent: dinsdag 14 september 2010 0:56
> To: dev_at_subversion.apache.org
> Subject: In svn_subst_translate_string(), shouldn't REPAIR in the call
> to svn_subst_translate_cstring2() be TRUE?
>
> Looking through the source code for `svn_subst_translate_string` in
> `subversion/libsvn_subr/subst.c`, it seems odd to me that the `repair`
> parameter to the call to `svn_subst_translate_cstring2` (for
> translating the line endings) is `FALSE`. `FALSE` means that if the
> line endings are inconsistent, then `svn_subst_translate_cstring2`
> fails.
>
> Given that the documentation for `svn_subst_translate_string` says
> that `value` is translated to LF line endings, which implies to me
> that all line endings are changed to Unix-style, shouldn't
> `svn_subst_translate_cstring2` be called with `repair` set to `TRUE`?

In most cases we translate to the normal form when the line ending style is consistent (all \r\n or \n) and we error out when it is inconsistent (at least one different form).

With inconsistent eol styles it is hard to guess what the original intent was.. so we ask the caller to fix it for us by returning an error.
(And this old function used to behave this way before we 'revved' it to integrate an optional repair functionality)

        Bert
Received on 2010-09-14 09:35:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.