> On Jun 1, 2017, at 8:32 AM, Alan Somers <asom...@freebsd.org> wrote: > > On Thu, Jun 1, 2017 at 9:11 AM, Marcel Moolenaar <mar...@xcllnt.net> wrote: >> >> On May 31, 2017, at 11:06 PM, Ngie Cooper (yaneurabeya) >> <yaneurab...@gmail.com> wrote: >> >> >> On May 31, 2017, at 10:03 PM, Brooks Davis <bro...@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@r319125 >> >> ^/head@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@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 >> mar...@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 mar...@xcllnt.net _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
