version control

[david at thekramers.net (David Kramer)]

Derek Atkins wrote:
> There are certainly arguments both ways..   But for quality control
> purposes it might make a lot of sense to store your released files
> in your SCCS.

The major argument for storing the binaries in your SCCS is that those
that aren't set up to build the source code (like possibly the Release
Engineers) can have access to the binaries to test or distribute them.

I feel VERY strongly that binaries are useless unless you can prove
beyond a shadow of a doubt that you know how they were built, and from
what source.  Unless you built it yourself, or it was built by an
automated process, vetted, then checked in, you can't prove that.  And
sometimes even if that *was* the process.

I designed and implemented a distributed, automated, cross-platform
build and test system for a company recently.  Of the four projects we
tested it with, three of them would not build.  You see, without the
automated system, only the developer working on the project ever built
it.  Of course it builds on his system.  But is what's on his system
exactly what's in version control?  Apparently not.  All three projects
were missing files that were never checked in, or had dependencies to
other projects that you just had to know about, and hope you got the
same version of.  I've had similar results in other companies without a
formal QA/RE team and plan.

If the binaries generated by that developer were shipped to a customer,
and that customer needed a change, there would be no way to recreate the
original build environment to make the change in it.

Here's another fun scenario.  Let's say you build your software on a
developer's machine, then you package it up, and send it to the
customer.  The customer needs a change, so you make your changes and
ship it to the customer.  Only the customer complains nothing changed.
Upon closer examination, they noticed that the executables that
implement that functionality are actually timestamped two months ago.
What happened?  Well, that binary stopped building two months ago due to
an error in the code, and nobody noticed, because the binary is still
there from the last successful build.  But it doesn't match the source
code anymore, and it certainly doesn't have the recently requested
change in it.  The moral equivalent of "make clean" will often catch
these problems, but only if done right.  My build system removes the
entire build directory and checks out the source from version control
each and every build.

The only way I would allow binaries to be checked into version control
on *my* watch would be if it was in a different directory than it gets
built in, so there's no mistake which binaries were built and which
binaries came from version control.

Furthermore, binary packages, by their very nature, do not change once
built.  Checking them into version control and never changing them is a
waste.  If you need to store binaries of builds, then set up a clean,
repeatable vettable build process, build there, have the right people
sign off on it, package it up, and put it on your NAS or intranet.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.