Date: Fri, 13 Jan 95 11:48:40 MST From: terry@cs.weber.edu (Terry Lambert) To: phk@ref.tfs.com (Poul-Henning Kamp) Cc: roberto@blaise.ibp.fr, dgy@seagull.rtd.com, freebsd-hackers@freefall.cdrom.com Subject: Re: CVS stuff Message-ID: <9501131848.AA10722@cs.weber.edu> In-Reply-To: <199501131627.IAA03431@ref.tfs.com> from "Poul-Henning Kamp" at Jan 13, 95 08:27:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > If we are talking about the FreeBSD CVS-tree: binaries are NOT welcome. > > > > ...then have a look in perl directory, in the t/ qnd the t/op/... > > > > There is a file coming from the 'make test' target for the .db. The files > > are named op.lib.db or such. > > > > They're definitely binary. I'm sure that I've seen others. > > I have a complete list already. If I had the time I would hunt them down, > as I did once before already. > > PLEASE DON'T COMMIT BINARIES INTO THE TREE. > > A good definition of "not binary": > > The file has no 0x00 or 0xff in it. > The last byte is 0x0a > diff(1) and vi(1) doesn't choke on it. This definition would fit a uuencoded binary. Is this acceptable? You could even put versioning in shell comments at the top. The advantage to binaries in the tree is that it allows for inclusion of binary-but-not-source-redistributable code. For instance, an Adaptec driver written with Adaptec non-disclosure and distributed as binary code. Or a Computone, or Arnet, or Digiboard driver. Or a Diamond VGA driver. Or the Intel/MACH math emulator, assuming Intel OK'ed it. The hack is to do auto encoding.decoding on insertion/extraction. And that's actually a deficiency in CVS that it doesn't do it already, but one that can be worked around with Makefile targets if one doesn't want to sully pure, clean CVS with the job. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501131848.AA10722>