[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> is 64A95EE5 (F1B83152). _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
