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

[Alan Somers]

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?
Subversion can handle that.  That way the tests won't need to decode
them, svn clients won't change their line endings, and commit mail
won't include their diffs.

-Alan