CVS is intended to handle source control for files in three major situations: 1. Multiple developers working on the same files.The major advantage of using CVS over the simpler tools like RCS or SCCS is that it allows multiple developers to work on the same sources at the same time.The shared Repository provides a rendezvous for committed sources that allows developers a fair amount of flexibility in how often to publish (via the "commit" command) changes or include work committed by others (via the "update" command). 2. Tracking a stream of releases from a source vendor.If you are making changes to sources distributed by someone else, the CVS feature, called the Vendor Branch, allows you to combine local modifications with repeated vendor releases.I have found this most useful when dealing with sources from three major classes of source vendor: a. Large companies who send you tapes full of the latest release (e.g. Unix OS vendors, database companies). b. Public Domain software which *always* requires work. c. Pseudo-Public sources which may require work. (e.g. GNU programs, X, CVS itself, etc.) 3. Branching development.Aside from the "Vendor Branch", there are three kinds of "branches in development" that CVS can support: a. Your working directory can be treated as a private branch. b. A Development branch can be shared by one or more developers. c. At release time, a branch is usually created for bug fixes. (See 1D.9 and Section 4C for more info on branches.) CVS's branch support is a bit primitive, but it was designed to allow you to create branches, work on them for while and merge them back into the main line of development.You should also be able to merge work performed on the main branch into the branch you are working on. Arbitrary sharing and merging between branches is not currently supported.