Re: Appropriate use of CVS for final executables

[Paul Sander]

On Friday, April 26, 2002, at 06:57  AM, address@hidden wrote:

> Should CVS be used to stored the executable that is generated at the end
> of a build process under a special directory, say release/ ?

Not in-place.  Doing so would interfere with the normal development 
process because you're automatically modifying files that are under 
source control. This is usually a bad idea in a CVS environment because 
the notion of "up-to-date" becomes corrupted.

If it becomes a requirement to check in a released product, what I would 
do is populate a release tree or archive and check that in.  But in 
practice, I've yet to run into a case where it's necessary to do so.

> Some people argue that, just like CVS is able to store source files and
> attach versions to these files, we should store "ALSO" the final product
> (a library or executable, etc) in CVS and link them with the same "tag".
> This way, they argue, any one who wants to go back to back and try an
> earlier version of a module, can just checkout an earlier version of the
> module and access the executable (or the library whatever)..

When someone wants to go back to prior released products, they usually 
either want the source code for maintenance, or they want the 
installable image for normal use.  Rarely do they really want both, and 
those who really want both are usually clueful enough to know how to 
find both, but having pointers of some kind (e.g. consistent tagging 
conventions) helps a lot.

> Is this approach sound?
>
> This is suggested by people who has used Clearcase and/or MKS.

What the ClearCase users don't tell you is that when someone checks in a 
"derived object" (typically a shippable), they really check in not only 
the bits but also the "configuration record".  (Actually, checking in 
the bits is optional but included by default.)  The configuration record 
includes all of the steps necessary to reproduce the bits, including the 
makefile recipe that built it, makefile variable settings, environment 
variable settings, contributing source files and their version numbers, 
and a whole bunch of other stuff.  This makes it possible to use 
ClearCase' wink-in feature to reuse stored bits, or to produce 
equivalent results if the bits have been scrubbed.

> Another supporting argument they have is that is is not always possible
> to reproduce the same executable shipped to a customer exactly as it is,
> due to many reasons.

This argument has some validity; it's often impossible to get 
bit-for-bit identical output from a compiler given identical sources.  
(Many compilers embed timestamps or other invisible data in a half-baked 
attempt to provide a means to uniquely identify their outputs using 
special tools.)  If getting bit-for-bit identical results is indeed a 
requirement, then archiving the output is the only way to go.  But if 
(as in most cases) bug-for-bug compatibility is the requirement, then 
saving the process and environment to repeat the build identically is 
sufficient.

> My questions are :
> 1) Can CVS nicely handle binaries? If yes OR no, can you pls giev some
> technical detail how?

CVS can handle binaries, but it does so in a manner that makes it more 
trouble than it's worth.  In the context you describe, there are other 
drawbacks that make it highly undesirable.

> 2) Is the suggest approach of storing the executables a correct SCM
> practice? - People have argued that this is what they have done, AND
> they clearly needed to this that way. Doint otherwise, were creating
> many more problems.

I've yet to come into a situation where I've had to check in the results 
of a build.  It's better to record the process as that's your ultimate 
backup than to simply save the bits.  The bits can be useful, but having 
them is only one method to meet the reproducibility requirement that can 
(and in my opinion should) be used only as a supplement to something 
else.

> Comments / feedback greatly appeciated.
>
> -Arcin