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

Re: Wrong assumption about unidiff syntax in libsvn_diff?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 20 Nov 2012 15:00:33 +0000 (GMT)

Branko Čibej wrote:

> On 20.11.2012 15:05, Stefan Sperling wrote:
>> On Tue, Nov 20, 2012 at 11:25:30AM +0100, Branko Čibej wrote:
>>> I was under the impression that we already cleared up this
>>> misconception? Only the leading backslash and space are important
>>> for signaling the no-trailing-eoln state. The text itself can be
>>> localized, or absent.
>>>
>>> I'm pretty sure we should mark the "No newline at end of file"
>>> for translation -- but /not/ the "\\ ".
>>
>> svn patch relies on the comment being present and not being localised.
>> See parse_diff.c:parse_next_hunk().
>>
>> If we change diff_memory.c the diff parser should also be changed
>> to not rely on this string being present (we can't recognise
>> translated versions in the parser obviously).
>>
>> I just checked the UNIX patch code shipped with OpenBSD and it seems
>> you're right that it only looks for the backslash and ignores the
>> comment.
>>
>> However, it seems in practice patches usually contain this string in
>> non-localised form. At least nobody has yet complained about svn patch
>> misparsing such patches.
>
> I'm distinctly remember a report on this very list, with a unidiff with
> a localized message attached. However, I can't find it in the archives.
> In any case it would be nice if our diff parser only looked at the \,
> not the whole message. I'm less worried about our not localizing that
> particular string.

Let's fix the parser to require only '\' and leave the string untranslated.  "Be conservative in what you send and liberal in what you accept" is a good mantra for interoperability.

- Julian
Received on 2012-11-20 16:01:12 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.