Re: Is it a good idea to use CVS for this??

[Greg A. Woods]

[ On Monday, October 15, 2001 at 12:18:29 (-0400), address@hidden wrote: ]
> Subject: Is it a good idea to use CVS for this??
>
> Well, one coworker has suggested storing the output of the build process (
> that is, the final executables, dlls, etc. ) in CVS.  He makes some good
> arguments that this stuff should be archived, which I agree with.  But, I
> have some reservations about putting it in CVS.  I can't however, put my
> finger on exactly why I think CVS isn't the best place for this stuff.

I would say you do not ever want to try to put generated files in CVS,
especially not in the same module as the sources are in.

First off CVS is not at all suited for binary files, which your
executables are most certainly to be.  This alone should be reason
enough to avoid using CVS to archive build targets.

CVS is not suited for derived files no matter what their internal
structure.  I won't delve into the reasons why -- it should be obvious,
but if not you'll have to take my word for it.  I'll talk more about
verifying builds below.

You certainly do not ever want to archive every build done by every
user, regardless of how you archive any builds -- that would be
pointless, confusing, and still wasteful even in this day and age of
150-GB disk drives.  If one user checks in an executable it will almost
certainly _always_ conflict with any other build of that same
executable, even if the exact same sources are used (most compilers
include timestamps or other runtime information, and some compilers
include the source directory pathnames too, eg. gcc with '-g').

If you want to archive build targets then only archive milestone builds
created from tagged sources, and do it as a tar/zip/whatever archive
labeled with the same tag name they were derrived from in the sources.

You'll also want to include in that archive information about the build
environment, including revisions of all tools used, including the base
OS, environment variable settings, command-lines used to initiate the
build, etc.

So, why archive any build targets?  Well one good reason is of course to
ensure that builds are reproducible.  This of course implies that you
"archive" the sources too, and of course that's effectively what you're
doing when you tag them.  The reason you also include all the other
information about the build environment is of course because it's also
part of the set of components used to create the targets.

Your archives could take many forms though -- rumours abound about some
folks who archive the whole build machine!  ;-) Generally though I think
you could get by with archiving just the files used to install the
resulting targets onto a machine where they'll actually be used.  If
part of your process is to "burn" installation media, then just include
on it the additional build environment info, label it with the tag name,
and you're done!

Another reason some folks claim for archiving intermediate build
products is that their use can greatly simplify the buiding of complex
software when only tiny components are changed.  I don't think this is a
very good process though -- a much better process is to break the large
project down into smaller internal projects which are separately release
managed and to "install" their products on your build machines such that
they can then be used by full-system builds.  This way you can even
simultaneously install several different releases of the sub-projects
and have full-system builds choose from amongst them as necessary.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>