80104 2012-03-01 23:22:03 -0800 ./Tools/Scripts/svn-apply fails while trying to process patch generated with png(binary) file. 2012-10-08 23:13:42 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 80762 P2 Normal --- 0 ssandela webkit-unassigned dbates kbolisetty mrahaman ssandela oldest_to_newest 569317 0 ssandela 2012-03-01 23:22:03 -0800 It is found that when we run 'svn-create-patch' involving a png file, the patch has following characters in it. Property changes on: abc.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +image/png which svn-apply is not able to process. The above characters are footer data when "svn-diff --diff-cmd -diff abc.png" is run inside svn-apply, which VCSUtils.pm is not able to process. Because of this, patches generated on Windows(Win-7, Cygwin, svn1.7.2) and Linux terminals are failing on build bots. When svn-create-patch is run on MAC Machine, there is no such issue and it generates following kind of footer. Property changes on: abc.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream which is of-course being processed by svn-apply script through VCSUtils.pm file. 569489 1 ssandela 2012-03-02 03:04:45 -0800 One more observation is that, the MAC machine i used has svn version 1.6.17. So, i think it has got some thing to do with svn1.7+ Release. As from following link http://subversion.apache.org/docs/release-notes/1.7.html#diff-properties looks these characters are valid and should be handled by the script. 570103 2 ssandela 2012-03-02 19:58:38 -0800 Looks like, mime-type detection with libmagic in svn1.7+ switches the automatically configured mime-type from 'application/octet-stream' to 'image/png'. http://subversion.apache.org/docs/release-notes/1.7.html#libmagic-support so any one stuck with this problem, can for the time being compile svn with out libmagic support. 737439 3 dbates 2012-10-08 23:13:42 -0700 *** This bug has been marked as a duplicate of bug 80762 ***