RE: svn commit: r1704374 - in /subversion/trunk/subversion: include/svn_diff.h include/svn_error_codes.h libsvn_diff/binary_diff.c libsvn_diff/diff.h libsvn_diff/parse-diff.c tests/cmdline/patch_tests.py

> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: woensdag 23 september 2015 14:51
> To: Julian Foad <julianfoad_at_btopenworld.com>
> Cc: Bert Huijben <bert_at_qqmail.nl>; Stefan Sperling <stsp_at_elego.de>; dev
> <dev_at_subversion.apache.org>
> Subject: Re: svn commit: r1704374 - in /subversion/trunk/subversion:
> include/svn_diff.h include/svn_error_codes.h libsvn_diff/binary_diff.c
> libsvn_diff/diff.h libsvn_diff/parse-diff.c tests/cmdline/patch_tests.py

> Without completely understanding how the binary diff / patch is now
> implemented, I'd say: better to error out in this case. If it helps
> detecting corruption of the binary diff (say it was randomly changed
> by some wire transmission) ...

This is completely against the rest of the patch implementation, and how other diff implementations work.

For many reasons (including: legacy, compatibility, etc.) all of them ignore everything they don't understand. The current (1.8/1.9) patch code just ignores these hunks and doesn't error on them.

The patch code only errors out on fatal errors.

While it would be nice to error out and say the user should get a good file, there is no way he can.

Hand editing binary patches (that are typically gzipped binary blobs internally) is virtually impossible and you can't trust the content came from some trusted source anyway. You should always review the resulting binary when you get it from an untrusted source. (The same applies to unified diffs, but reviewing those is much easier :-))

        Bert
Received on 2015-09-23 15:34:46 CEST