svn commit: r319295 - head/usr.bin/mkimg/tests

[Marcel Moolenaar]

> On Jun 1, 2017, at 8:32 AM, Alan Somers <asomers at freebsd.org> wrote:
> 
> On Thu, Jun 1, 2017 at 9:11 AM, Marcel Moolenaar <marcel at xcllnt.net> wrote:
>> 
>> On May 31, 2017, at 11:06 PM, Ngie Cooper (yaneurabeya)
>> <yaneurabeya at gmail.com> wrote:
>> 
>> 
>> On May 31, 2017, at 10:03 PM, Brooks Davis <brooks at FreeBSD.org> wrote:
>> 
>> On Wed, May 31, 2017 at 08:01:12AM +0000, Ngie Cooper wrote:
>> 
>> Author: ngie
>> Date: Wed May 31 08:01:12 2017
>> New Revision: 319295
>> URL: https://svnweb.freebsd.org/changeset/base/319295
>> 
>> Log:
>> Update the usr.bin/mkimg golden test output files after ^/head at r319125
>> 
>> ^/head at r319125 changed the location of the backup pmbr, requiring the
>> output files to be regenerated, since they're binary disk dumps.
>> 
>> The output files were regenerated with "make rebase"--fixed in
>> ^/head at r319294.
>> 
>> 
>> These should not be stored uuencoded.  It serves no purpose other
>> than bloating the repo and causing spammy commit mails like this one
>> where we got a huge tail of garbage output.
>> 
>> 
>> Hi Brooks,
>> I’m not entirely sure why the files were uuencoded to be honest. I think
>> that’s a good question for Marcel and some of the folks at Juniper, since
>> they wrote the tool/tests.
>> 
>> 
>> Result files used to start off as binary files.  uuencoding is a given in
>> that case.  I eventually switched to using hexdump -C, because that makes it
>> easier to analyze and understand differences.  The uuencoding was kept to
>> remain independent of version control system, file attributes and
>> end-of-line characteristics of the host machine: nothing more annoying that
>> checking out textual result files and have test failures because ‘\n’ was
>> replaced by ‘\r\n’.
>> 
>> Even if the files aren’t unencoded, there’s always someone who treats it as
>> spammy and a tail of garbage. It’s just a knee-jerk reaction to seeing
>> something that isn’t understood, I think. As such, there’s no reason to
>> change — in fact, changing would be bloating the repo.
>> 
>> --
>> Marcel Moolenaar
>> marcel at xcllnt.net
> 
> If the files are binary, then why not store them as binary files?

A 100MB image, committed as binary file is 100MB of data. The hexdump -C
equivalent is often only a few hundred bytes (due to the many zeroes).
The repo bloat argument has grounds for binary files.

-- 
Marcel Moolenaar
marcel at xcllnt.net