Re: Countering the usual diatribe against binary files, was cvs diff, proposal for change

[Paul Sander]

>--- Forwarded mail from address@hidden

>On Tue, 9 Sep 2003, Tom Copeland wrote:

>> On Tue, 2003-09-09 at 12:12, Kaz Kylheku wrote:
>> > On Tue, 9 Sep 2003, Tom Copeland wrote:
>> > > On Mon, 2003-09-08 at 16:00, Greg A. Woods wrote:
>> > > > I can import gigabytes and terabytes of binaries into CVS too, but no
>> > > > matter how much I try I'll never be able to use branches meaningfully 
>> > > > in
>> > > > such a repository, 
>> > > 
>> > > Hm.  Do CVS branches not work right with binary files?  I've used
>> > > repositories that had lots of binary files (mostly jar files) checked
>> > > into them with lots of branches and haven't seen problems yet...
>> > 
>> > JAR files are derived objects, not primary objects.
>> 
>> Right... although in the case of 3rd party libraries, the line gets a
>> bit blurry.  If my project depends on, say, BCEL, I think it's
>> reasonable for me to check the BCEL jar file into my module/lib
>> directory.

>Not necesarily. Your project also depends on some operating systems and
>libraries. You don't check in glibc2, the Linux kernel, or every
>Windows DLL that your program uses. Your makefile needs GNU make 3.79
>or later, so better check that in too!

I have worked in environments (in Unix) where the entire tool chain,
along with compilers, system headers and libraries, standard utilities,
and everything, were checked in and run in a chroot environment.  I have
personally version controlled the hardware, though not with CVS...  (Sound
crazy?  Try building a product from scratch that's bug-for-bug identical to
an earlier release after upgranding an operating system, then have the
customer test it on an old installation.  Believe me, it's far preferable
to keep old build machines in mothballs.)

>Sometimes it's okay for binary components and tools to come from
>outside of the version control system, subject to some constraints like
>``requires glibc 2.1.3 or later, and Linux kernel 2.4.43 or later''.

Control what you can, remember what you can't.  If you can match the
proper tool chain with the source code then you don't have to check in the
tools.  Some people find it easier to check them in.

My preference is to check in third-party products that contribute to the
product in the way that source code does.  Stuff like the tool chain and
the OS I'm content to remember in the form of version numbers collected
in a file that can be diff'ed at a later time.  Whenever a build runs,
it's sometimes useful to diff such data with that from the prior build to
detect changes to the build environment.  When reproducing an old build,
I collect the data from the build host and compare it with that collected
by the original build and flag differences as warnings.

The data that I collect include things like the following:
- The output of uname to get the OS major and minor version numbers.
- A list of patches that have been applied to the machine.
- Mount points, including automounts.
- A list of installed packages and versions installed on the machine.
- For tools not installed with the OS or in packages (e.g. Gnu tools), the
  version number as produced by a command line option.  If no such option
  is available then I use a checksum.  Ditto for libraries that I link with.

Though I have not needed to track the following, I can see some value in
doing so:
- Sizes of memory, swap, and temp partitions.
- License keys.

>--- End of forwarded message from address@hidden