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

[Brooks Davis]

On Thu, Jun 01, 2017 at 08:11:45AM -0700, Marcel Moolenaar 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.

hexdump -C would make sense.  Direct commits of the compressed files
would also make sense.

Uuencoding gzip'd data is absurd given that we don't (and never again will)
support repositories that don't support binary data.  The diffs produced
are meaningless.

I don't advocate replacing these files agressively, but when updating
files we should be thinking about switching away from uuencoding.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170601/200aad12/attachment.sig>