Re: Appropriate use of CVS for final executables

[Greg A. Woods]

[ On , April 26, 2002 at 09:57:38 (-0400), Arcin Bozkurt wrote: ]
> Subject: Appropriate use of CVS for final executables
>
> 
> Should CVS be used to stored the executable that is generated at the end
> of a build process under a special directory, say release/ ?
> 
> 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".

Those people who argue such a stupid approach to version tracking have a
really narrow and short-sighted view of the bigger software
configuration managment picture, and they also seem to completely lack
all forms of imagination and creativity.

You do not need to have all objects stored in the same repository just
so you can associate a given symbolic identifier with their different
versions.  It really is just a simple matter of defining your naming
conventions and using them consistently.  If you don't want all your
symbolic names to have the same form (eg. internal tag names, which have
certain limitations of form) vs. marketing release names) then it's a
simple matter to define an algorithm that can translate back and forth
between the forms without information loss.  Even if your algorithm is a
simple as a table lookup then you have a solid and extensible solution.

> 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)..

I think that's a bad idea in general.  One of of the things you should
have very high up on your list of software configuration management
priorities is reproducibility of builds.  Storing products in the
version control repository really does make people very lazy.  They
think they'll never have to reproduce anything (but it's almost certain
that they will have to)!

It's also a very bad idea to store products in the version control
repository when using you're using CVS due to the fact CVS really cannot
effectively manage non-text files and quite often most product files are
not text files.

That's not to say that you shouldn't keep archive copies of milestone
builds of course.  You should -- just not in CVS, and you shouldn't be
using them regularly except to compare with re-builds of the "old"
sources and verify your ability to do reproducible builds.  If your tag
and archive naming schemes have a direct algorithmic relationship you'll
never have to worry about finding the right release tag to associate
with a given build -- just re-compute one from the other.  It's very
very very important to understand that you can quite easily keep safe
archive copies of things without putting them in a source code version
control repository!  Once you get rid of this stupid idea that there
should be one repository for everything then suddenly all kinds of new
and more efficient and effective ways of storing things like release
product archives come to mind!

Then once you re-compute the tag name from the release name you can
check out the sources for that build, see if you can reproduce the build
-- at least with functionally identical products (the same bugs are
demonstrable) if not bit-for-bit identical.  Then you can test a bug fix
against those sources and see if they fix one of those particular bugs
(and don't introduce new bugs or other unwanted changes).

-- 
                                                                Greg A. Woods

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