[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: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 20 Nov 2012 15:05:08 +0100

On Tue, Nov 20, 2012 at 11:25:30AM +0100, Branko Čibej wrote:
> I'm digging through libsvn_diff and found this snippet in diff_memory.c:
> SVN_ERR(svn_utf_cstring_from_utf8_ex2
> (&out_str,
> /* The string below is intentionally not marked for translation:
> it's vital to correct operation of the diff(1)/patch(1)
> program pair. */
> APR_EOL_STR "\\ No newline at end of file" APR_EOL_STR,
> btn->header_encoding, btn->pool));
> 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.
Received on 2012-11-20 15:06:01 CET

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