CVS Best Practices

Vivek Venugopalan

Revision History

Table of Contents

Introduction
Copyright Information
Disclaimer
New Versions
Credits
Feedback
Focus Areas
Using GUI Tools
Use GUI CVS client
Developer Sandbox
Keep System clocks in Sync
Do not share the sandbox
Stay in sync with the repository
Do not work outside the sandbox
Cleanup after Completion
Check-in Often
CVS Server Configuration
CVS access control
Server side scripting
Server Notification
Branching and Merging
Assign ownership to Trunk and Branches
Tag each release
Create a branch after each release
Make bug fixes to branches only
Make patch releases from branches only
Change Propagation
Merge branch with the trunk after release
Software Builds
Build Early and Build Often (BEBO)
Automate build Process completely
All necessary files must be checked-in before build
Institutionalize CVS in the Organization
Implement Change Management Process
Make CVS Usage part of Objectives
Collect metrics on CVS usage
Best Practices in Action
Inception
Development and Delivery
Conclusion
A. GNU Free Documentation License
0. Preamble
1. Applicability and Definitions
2. Verbatim Copying
3. Copying in Quantity
4. Modifications
5. Combining Documents
6. Collections of Documents
7. Aggregation with Independent Works
8. Translation
9. Termination
10. Future Revisions of this License
How to use this License for your documents

Abstract

This article explores some of the best practices that can be adopted while using CVS as the configuration management tool in your software projects.

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.

[Note]Note

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. The Concurrent Versions System site where current informaton about CVS is available. Including the CVS manual.

  2. Karl Fogel's CVS book, Open Source Development with CVS is available online.

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, GNU Free Documentation License.

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.

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

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.

New Versions

The version of CVS Best Practices that you are currently reading is : 0.7.

The latest version of this document can be obtained from (In the order of latest version availability)

Credits

The list of people who have provided information, ideas and corrections in no particular order are.

  1. Jens-Uwe Mager

  2. Jorgen Grahn

  3. Thomas S. Urban

  4. Cam Mayor

  5. Sally Miller

  6. Niels Jakob Darger

Thank you folks - your feedback has helped me keep “CVS Best Practices” as a living document with constant revisions over the years.

Feedback

Feedback is most certainly welcome for this document. Without your insight, submission and input, CVS Best Practices wouldn't exist. Please send your additions, comments and criticisms to the following email address : .

Google
Webwww.sanchivi.com
CVS Best Practices