Versions

Resources are versioned in order to capture a snapshot of the current state of the resources at one specific point in time. Resources in CVS are versioned by tagging them with a version label. When a resource is versioned, it means that a non-modifiable copy of it can be retrieved from the repository.

Versioning a project saves the line up of all resource versions in the project. Resources other than projects (files and folders) can be versioned. However, it is more common to version entire projects together as the resources contained in a project are often highly interdependent. Projects can be versioned from the workspace or from the branch (including HEAD) in the CVS Repositories view. The difference between these two approaches is in deciding which child resource versions should be part of the project version.

When tagging a project as a version from the Workbench, the base revisions of the files in the Workbench are tagged as belonging to that version. This is the preferred method of versioning a project because you know exactly which file revisions will be in the version. This operation is allowed if you have outgoing changes or uncommitted changes. Uncommitted changes are simply ignored and resources with outgoing changes can still have their base revisions be part of the version. Versioning a project with uncommitted or outgoing changes is handy if you have to split the project at the point where you started making changes to the resources and commit the resources to another branch.

When tagging a project as a version from a branch in the CVS Repositories view, you are versioning whatever the latest resource versions are in the branch at that moment in time. You should not version your projects from the branch if you do not know what is committed in the branch. For this reason, versioning from the Workbench is often preferable.

Related reference
CVS