Re: Appropriate use of CVS for final executables

[Pierre Asselin]

In <address@hidden> Arcin Bozkurt <address@hidden> writes:


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

In general, no.


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

With CVS that would be error-prone:  you have to remember and cvs-add
the generated files with '-kb' before committing and tagging.


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

Why not checkout just the sources and rebuild?  Are you worried
about changes in the build environment?


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

You *are* worried about the build environment.  What about the
run-time environment?  How do you know the old executable will even
run?

Let's say the old executable does run, and you are able to reproduce
a reported bug.  Now what?   Aren't you going to rebuild when you fix
the bug?


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

Not well.  The diff algorithm still cuts the file at \n characters and
it will be working with potentially long binary "lines".  Therefore,
the space savings won't be as good as with sources.

Basically you're trying to use CVS as a closet:  no diffs, no merges.
A real closet would work just as well.