On Wed, Sep 23, 2015 at 3:34 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Johan Corveleyn [mailto:jcor...@gmail.com] >> Sent: woensdag 23 september 2015 14:51 >> To: Julian Foad <julianf...@btopenworld.com> >> Cc: Bert Huijben <b...@qqmail.nl>; Stefan Sperling <s...@elego.de>; dev >> <dev@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 :-)) >
Okay, understood. Thanks for explaining. -- Johan
