1. Introduction
Men have become the tools of their tools. | ||
| --Henry David Thoreau (1817-1862) | ||
This article outlines some of the best practices that can be adopted when Concurrent Versions System is used as the configuration management tool in your software project.
Concurrent Versions System (CVS) is an Open Source configuration management tool that is now being looked at seriously by many commercial organizations as a viable alternative to other commercial Software configuration management tools.
This spotlight on CVS has led to the inevitable question of best practices for deploying CVS as the backbone SCM tool for large software development projects. Having answered this question many times verbally as a bunch of "gotchas" on CVS, it was time to put down on paper some of the best practices that will work well for CVS based projects.
 | This paper assumes that the reader is familiar with the fundamentals of software version control. Including features like branching, merging, tagging (labelling) etc., offered by modern version control tools such as CVS Further, This paper is not an introduction to CVS and its usage. There are excellent articles available on the net for the same. This paper assumes that the reader is familiar with CVS commands and is looking at deploying CVS in his or her organization. Some of the popular CVS related links that can provide CVS education are.
|
1.1. Copyright Information
This document is Copyright © 2001 Vivek Venugopalan. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found in Appendix A.
This document may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.
All translations, derivative works, or aggregate works incorporating this document must be covered under this copyright notice. That is, you may not produce a derivative work from this document and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the author at the address given below.
In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the document, and would like to be notified of any plans to redistribute the same.
1.2. Disclaimer
No liability for the contents of this document can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility for that.
All copyrights are held by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.
Naming of particular products or brands should not be seen as endorsements.
You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.
1.3. New Versions
The version number of this document is 0.6.
The latest version of this document can be obtained from
1.4. Credits
The list of people who have provided information and correction for this paper in no particular order are.
Jens-Uwe Mager
Jorgen Grahn
Thomas S. Urban
Cam Mayor
Sally Miller
Niels Jakob Darger
1.5. Feedback
Feedback is most certainly welcome for this document. Without your submissions and input, this document wouldn't exist. Please send your additions, comments and criticisms to the following email address : <vivek at magic-cauldron.com>.