Using CVS

This section applies only to packages using CVS at

Include the $Id$ CVS keyword in each file. As each file is edited, add this tag if it's not yet present (or replace existing forms such as "Last Modified:", etc.).

The rest of this section assumes that you have basic knowledge about CVS tags and branches.

CVS tags are used to label which revisions of the files in your package belong to a given release. Below is a list of the required and suggested CVS tags:


(required) Used for tagging a release. If you don't use it, there's no way to go back and retrieve your package from the CVS server in the state it was in at the time of the release.


(branch, optional) If you feel you need to roll out a release candidate before releasing, it's a good idea to make a branch for it so you can isolate the release and apply only those critical fixes before the actual release. Meanwhile, normal development may continue on the main trunk.


(branch, optional) If you need to make "micro-releases" (for example 1.2.1 and so on after 1.2), you can use a branch for that too, if your main trunk is very active and you want only minor changes between your micro-releases.

Only the RELEASE tag is required, the rest are recommended for your convenience.

Below is an example of how to tag the 1.2 release of the "Money_Fast" package:

$ cd pear/Money_Fast
$ cvs tag RELEASE_1_2
T Fast.php
T package.xml

By doing this you make it possible for the PEAR web site to take you through the rest of your release process.

Here's an example of how to create a QA branch:

$ cvs tag QA_2_0_BP
$ cvs rtag -b -r QA_2_0_BP QA_2_0
$ cvs update -r QA_2_0
$ cvs tag RELEASE_2_0RC1
...and then the actual release, from the same branch:
$ cvs tag RELEASE_2_0

The "QA_2_0_BP" tag is a "branch point" tag, which is the start point of the tag. It's always a good idea to start a CVS branch from such branch points. MAINT branches may use the RELEASE tag as their branch point.