On Friday, April 26, 2002, at 06:57 AM, [EMAIL PROTECTED] 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
