Abstract
Each submitted version of a file to RCS is given a version number. Each version is given more information than just an arbitrary version number. Descriptive notes about versions should be added to each version by the individual submitting the changes. However, version numbers are used as a numerical shorthand to represent versions.
Version numbers are strings composed of numerical digits and periods (.), examples include 1.1, 1.2, 1.23, 2.3.1.1 and 4.271.4.3. These numbers obviously specify the number of versions but also have other implied meanings about a version. The periods separating the numbers break up the different components of a version number. Each of these numbers gives hints about a version of a file or the file's history.
The first number in a version number is always the release number. For example, for the version number 1.2, the release number is 1. The release number for the version number 21.16.3.1 is 21.
The release number is largely arbitrary. The initial release number of a file committed to RCS is one, resulting in an initial version number of 1.1. Incrementing the release number is decided by the user at their discretion. If a number of changes to a file results in what the author concludes is a different or new file, then they could increment the release number to separate future edits from past edits.
This notation is a legacy of software development and their projects and products which are released with version numbers. Examples of software project versions include Gnu Emacs 19, RCS 5.7 or Linux 2.0.36. Changes from version like 4 to 5, or from 3.23 to 3.24 represent major or minor changes based on the judgment of the author or authors. This philosophy should similarly by applied to files in RCS.
Numerous changes to a file that are logged with RCS will fail to separate major changes from minor ones. Changing the release number at well judged states of the file can help with retrieving older versions. Changing the release number too willingly can result in too numerous release numbers that can also hide where the substantial changes are.
The last number in a version number is a revision number. The revision number for the version number 1.1 is 1. The release number for the version number 2.34.1.3 is 3.
The revision number represents how many different versions have been made to a file. RCS automatically increases the revision number when a new version of a file is submitted, or can be specified by the user but must be a number greater than the current version.
Similar to release numbers (see section on release numbers), numerous revisions to a file should be submitted often to RCS. Increasing the number of revisions along with notes that describe the changes made in the revision help better separate the changes made to a file over time. A large number of submitted changes to RCS resulting in large revision numbers will fail to make it clear which were groups of changes that made a major difference and which were only minor ones. This is where the feature of release numbers allows one to categorize major groups of changes as a release number. For example, after starting a file with version 1.1 then making dozens of changes until version 1.27 the author could decide to have these versions be part of release 1 and begin release 2 with version 2.1.
A branch number is a number appended to a version number (see section on version number), representing a branch (see section on branch) in revisions (see section on revision) to a version of the file. The version number 2.3 would have its first branch number be 2.3.1. Now 2.3.1 is not a full version number. It says that revision number 3 of release number 2 was branched once. What about revisions to the branch? The first revision number on this branch is 1 resulting in the version number 2.3.1.1. To review, the branch number on the version number 1.7.3.5 is 3.
The branch number represents how many branches have occurred to a version. RCS does not require the first branch to be 1. When a branch to a version is desired, choose a branch number. Good practice would have branch numbers represent the actual number of branches.
More could be added here
Like branch numbers (see section on branch numbers), tree numbers are version numbers with a specific format. Branch numbers are version numbers (see section on version numbers) with a branch number. Tree numbers take the form of a version number (see section on version numbers) without a branch number.
Of course this is a logical corollary, but is a necessary point because a revision is only located on the main tree only if it has a tree version number. The version number 1.1 and 19.84 are examples of tree numbers. All other number formats are branch numbers. Branch numbers can never represent versions on the trunk.