[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Appropriate use of CVS for final executables
From: |
Paul Sander |
Subject: |
Re: Appropriate use of CVS for final executables |
Date: |
Fri, 26 Apr 2002 15:46:22 -0700 |
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