Re: Is it a good idea to use CVS for this??

[James Youngman]

address@hidden writes:

> Hello all, I have been having an interesting discussion with a co-worker,
> and am looking for some additional thoughts.   My organization is just
> adopting CVS, and source code management.  ( don't even ask how we did it
> in the past, you don't wanna know ).   Anyway, we have been discussing
> exactly what to store in CVS, and some details as to the who, what, when
> were and how, of using CVS.
> 
> Well, one coworker has suggested storing the output of the build process (
> that is, the final executables, dlls, etc. ) in CVS.  He makes some good
> arguments that this stuff should be archived, which I agree with.  But, I
> have some reservations about putting it in CVS.  I can't however, put my
> finger on exactly why I think CVS isn't the best place for this stuff.
> 
> So, if anyone could share their thoughts with me, pro or con, I'd highly
> appreciate it.  Do any of you store executables in CVS?  What good reasons
> exist, if any, for doing this? Conversely, what good reasons, if any, exist
> for NOT doing it?
> 
> Thanks!


I'm assuming here that you develop software and provide it to
(internal or external) customers.

CVS is a configuration management system that supports the version
management of sets of what for want of a better word we shall call
source code.  This can be more or less any kind of text file which is
produced by humans.  CVS is not really aimed at the configuration
management of lumps of arbitrary data.   

Something that CVS is good for is to support the development of
software by teams of people.  It supports the ability of people to
check their code into a management system that will allow them to
revert to a previous version at will.  You can even work on a line of
development (i.e. "branch") completely separately from your
colleagues.   This is all good and useful.  

However, CVS's operation is pretty much based on the assumption that
the files you are working with can be compared with diff and perhaps
merged.  While it's not true that it fails to operate at all with
binary files, it would be true to say that some of CVS's distinctive
advantages do not apply to binary files, and that occasionally you can
get yourself into an awkward corner with CVS if you're not dealing
with "real" source code type text files.  I'm not saying that CVS will
eat your files unless they are real source code, I just mean that the
greater the departure of your usage pattern from the case for which
CVS is designed, the less well it will apply to your situation.

I'm also assuming by the way that your colleague is _not_ suggesting
that the output of the build system be stored in the _same_ module as
the source code. 

So, if you use CVS for your source code it will certainly work well,
and is certainly a good idea.  You implied by the way that you didn't
have effective version management procedures before; don't
underestimate the need for training and transition guidance.

However, if you are shipping code to customers you will also have a
requirement to retain copies of previous releases made to customers,
and potentially
1. Copies of the software, exactly as distributed to the customers
2. Copies of the documentation, exactly as distributed to the customers
3. Records of which customer got what version (and perhaps when)
4. Licensing information 
5. Records of which tools were required to build the software

That's a lot of stuff.  While you could perhaps put (1) into CVS, CVS
is not suitable for 2, 3, 4 and probably 5.  You need to put extra
procedures in place for tracking tools and releases.   CVS alone does
not do this.   

In order to be maximally effective in reproducing past releases (and
you should think about to what extent this is useful for you and how
much effort you want to put into it) you could keep complete records
of this stuff.

But keeping the exact contents of releases probably means a bunch of
big binary files.  It's probably not to useful to compare these
against their predecessors, except perhaps to identify those which
didn't change at all.  CVS is not so hot for binary files and in any
case doesn't quite do the job (e.g. CVS produces a directory tree, is
this what you provide to your client?   Unlikely).  

In our case, our release to the client is a wad of documentation and
some tar files, all on a CD-ROM.  We keep the tar files archived and
the documents too.  We usually keep the CDs also.  This means that if
the customer reports a problem we are _completely certain_ that we can
lay our hands on exactly the same thing as they used to install the
software, even down to the setup files / packaging etc.  This means
that we have a good expectation of reproducing their problem.  If you
can't reproduce the customer's problem it's either because 

(1) they have some weird configuration of your software
(2) they aren't telling you all the relevant information
(4) they are mistaken
(8) you're not doing it right
(16) you have differing setups
(32) neither of you understands how the software works

However, if you can reproduce the problem and the client has an old
version, you may need to use an older set of tools to fix the problem
in their old release (some shops just don't have to do this though -
they decline to support customers on very old versions).


I'm aware of the fact that I'm rambling a bit here, but what I'm
trying to say is that in order to effectively reproduce a customer's
environment for the purpose of reproducing and fixing problems, there
are many issues that CVS does not address (some shops even keep entire
_hardware_ systems archived for some projects - try doing that with
CVS).

In short, what I am trying to say is that CVS is a very powerful
version management tool, but it is not a Configuration Management
"silver bullet".  It cannot solve all the problem, and is not designed
to.  It sounds like your colleague's expectations of CVS exceed its
actual capabilities.  

While you could use CVS to store and recover the files comprising a
release (use a completely separate module!), it is unlikely to be
preserving them in the same format as actually presented to the
customer, and there are lots of related problems that CVS doesn't
address at all.  Devote some thought to your configuration management
scheme; device where on the continuum between A and Z that you exist:-

A: "throw it all away, I only want the current version of each
source file" 

Z: "keep every working version of every source file, the built files,
the development tools, the OS and the hardware too, also the
customer's OS and hardware - oh, and freeze-dry the developers while
you're there, they might not have written it all down."

Obviously neither A nor Z is realistic, but you need to figure out
where you fall and devise an appropriate CM strategy.  CVS is unlikely
to be the whole of the solution, even if it is an important or even
the most important part.  

This email could have been sorter, but I didn't take the time to set
out my thoughts in a more orderly fashion, sorry.

-- 
James Youngman
Manchester, UK.  +44 161 226 7339
PGP (GPG) key ID for <address@hidden> is 64A95EE5 (F1B83152).