Date: Thu, 1 Jun 2017 08:35:30 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Alan Somers <asomers@freebsd.org> Cc: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com>, Brooks Davis <brooks@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, "Simon J. Gerraty" <sjg@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r319295 - head/usr.bin/mkimg/tests Message-ID: <7BA69054-D85F-49B5-8EB0-948DFC1A998E@xcllnt.net> In-Reply-To: <CAOtMX2jogda9vzo-8PG6-YMk3kPjO8%2BhzLYGiZAMzFaepQc1-Q@mail.gmail.com> References: <201705310801.v4V81CjO004032@repo.freebsd.org> <20170601050339.GA48398@spindle.one-eyed-alien.net> <7FC9CB7D-CF96-4ACA-A38C-E82836127BA4@gmail.com> <78A8D734-A627-437D-AE63-BA94C543C36B@xcllnt.net> <CAOtMX2jogda9vzo-8PG6-YMk3kPjO8%2BhzLYGiZAMzFaepQc1-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 1, 2017, at 8:32 AM, Alan Somers <asomers@freebsd.org> wrote: >=20 > On Thu, Jun 1, 2017 at 9:11 AM, Marcel Moolenaar <marcel@xcllnt.net> = wrote: >>=20 >> On May 31, 2017, at 11:06 PM, Ngie Cooper (yaneurabeya) >> <yaneurabeya@gmail.com> wrote: >>=20 >>=20 >> On May 31, 2017, at 10:03 PM, Brooks Davis <brooks@FreeBSD.org> = wrote: >>=20 >> On Wed, May 31, 2017 at 08:01:12AM +0000, Ngie Cooper wrote: >>=20 >> Author: ngie >> Date: Wed May 31 08:01:12 2017 >> New Revision: 319295 >> URL: https://svnweb.freebsd.org/changeset/base/319295 >>=20 >> Log: >> Update the usr.bin/mkimg golden test output files after = ^/head@r319125 >>=20 >> ^/head@r319125 changed the location of the backup pmbr, requiring the >> output files to be regenerated, since they're binary disk dumps. >>=20 >> The output files were regenerated with "make rebase"--fixed in >> ^/head@r319294. >>=20 >>=20 >> 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. >>=20 >>=20 >> Hi Brooks, >> I=E2=80=99m not entirely sure why the files were uuencoded to be = honest. I think >> that=E2=80=99s a good question for Marcel and some of the folks at = Juniper, since >> they wrote the tool/tests. >>=20 >>=20 >> 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 = =E2=80=98\n=E2=80=99 was >> replaced by =E2=80=98\r\n=E2=80=99. >>=20 >> Even if the files aren=E2=80=99t unencoded, there=E2=80=99s always = someone who treats it as >> spammy and a tail of garbage. It=E2=80=99s just a knee-jerk reaction = to seeing >> something that isn=E2=80=99t understood, I think. As such, there=E2=80=99= s no reason to >> change =E2=80=94 in fact, changing would be bloating the repo. >>=20 >> -- >> Marcel Moolenaar >> marcel@xcllnt.net >=20 > 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. --=20 Marcel Moolenaar marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7BA69054-D85F-49B5-8EB0-948DFC1A998E>