When you perform an update, a baseline is used as a starting point to look for new changes. You can also compare two baselines to see what changes have been made relative to a particular build. If you use Rational Change, you can use baselines to generate change request reports.
Typically, a build manager creates a baseline; developers do not create a baseline because they do not make builds available to other users.
You might create a baseline as soon as you perform a build. You can create a baseline and make it available to the test group without making it available to all developers. Making the baseline as soon as you build saves a representation of the build in the database in case it is needed later to create a fix for a build.
Creating a baseline for each Integration Testing and System Testing build helps testers and developers to refer to the set of changes that were used to create the build. Typically, you create a baseline for all projects in the same release and purpose. For example, you would create a baseline for each Integration Testing build using all Integration Testing projects for that release.
Baselines can be used by process rules to define the baseline for the projects that use that template. For example, a build manager might create a baseline named Integration Build 20040913 containing static projects toolkit-int_20040913, calculator-int_20040913, and so on. The numeric designation is the date (yyyymmdd) the baseline was created.
A process rule specifies that its projects use a particular baseline. The projects that reference that process rule use the baseline to identify which baseline project to use when updating. For example, the Integration Testing process rule for the current release specifies to use the Integration Build 20040913 baseline. A development project called calculator-bob selects calculator-20040913 as its baseline project.
Using baselines has many benefits.
How a new baseline is created
Both prep state projects and static projects can be added to a new baseline. However, if a build management project is added to a baseline, the actual project is not added. Instead, a copy of the project is created and added to the baseline and checked in. Build management projects and their work areas are preserved as is so as not to cause unnecessary rebuilds. Moreover, new versions are checked out and checked in for all non-static products that are members of the build management project. The new project has the same members as the build management project. The new projects and products are checked in to the member_status that is associated with the purpose for the baseline. If member_status is not a valid state, the projects and products are checked in to the integrate state.
For example, a baseline that has the Integration Testing purpose has projects and products that are in the integrate state.
If a build management project contains any non-static members that are not projects or products, you cannot add it to a baseline. Before you can add such a project to a baseline, you must check in its non-static members. In addition, you cannot add to a baseline any project whose update properties include a task that is not complete.
A new project or new product version is created based on the build management project version, the date, and if necessary to make the version unique, an incremental number that is appended. For example, if project ccm_gui-sol_int is saved as part of a baseline, the new baseline project becomes something like ccm_gui-sol_int_20040709. If it is not possible to append an underscore, the date, and an incremental number (and stay within the limit of 32 characters), then just the date and the number are used.
After a baseline is created, the History View links are changed so that it appears that build management projects are checked out from the new baseline projects. Project histories are updated to look as though existing prep products are checked out from the products that are created for the baseline projects.
New projects that are created as part of a baseline do not have work areas. If you want the projects to have work areas, enable work area maintenance after the baseline is created. When a project that has a visible work area is added to a baseline, it is checked for work area conflicts. If any non-resolvable conflicts are found, the create baseline operation fails. To resolve this issue, you must reconcile the project.
If a project with a non-visible work area is added to a baseline, the latest-built product might not have been copied to the database. In such a case, the baseline contains what is in the database, not what is in the non-visible work area. To avoid this problem, the build manager must synchronize changes to all non-visible work areas of projects that are added to a baseline. Complete this operation before adding such projects to a baseline.
You must work as a build manager to create or release a baseline. You must work in the ccm_admin role to delete a baseline or modify the build of a released baseline.
Version template specification
A version_template is any string, with optional keywords, with the form %keyword or %{keyword}. The keyword can be any Rational® Synergy attribute, the special keyword %baseline_name, or the special keywords, %date and %build.
When an attribute is expanded, the corresponding attribute value from the build management project or product being examined is used. If no attribute or built-in keyword is found for a specified keyword name, the empty string is used to replace the keyword.
The versions of the project and product versions that became static when the baseline was created are updated to match version_template. However, projects that existed in a static state before the baseline was created are not reversioned. For example, a CM/6.5 SP2 baseline was created with 20 existing static projects from the CM/6.5 SP1 baseline and five new projects from the CM/6.5 SP2. Only the five new projects are reversioned.
If the instantiated version_template for any project or product in the baseline contains characters that are not allowed in a version string, those characters are replaced with the default version string replacement character. This is specified in the server ccm.ini file, with the option baseline_template_repl_char. This character default is an underscore (_). For example, if %platform is part of a version template, and the build management project has a platform of SPARC-solaris, then the version string contains the string SPARC_solaris. Or, if %release is part of a product version template, and the prep product has a release of CM/6.5, then the version string contains the string CM_6.5.
If the instantiated version_template for any project or product in the baseline is already in use for another version of that project or product, then the version is made unique by appending an underscore (_) and the first integer that makes the version unique, starting with 1. If this causes the version string to be too long, then a version based on the current date is used for that project or product. A warning is also given.
If –version_template is not specified, then the default (i.e., saved) template is used.
The work area is updated if the work area template for the project includes the version. If a work area cannot be updated because it is not visible, and -skip_nonvisible_projects is not used, the operation continues and all errors are reported. If the work area is visible, but cannot be updated for other reasons, such as lack of correct file permissions, the operation continues and all failures are reported.
Alternate keyword syntax for version template
The keyword syntax provides a way to alter the expansion behavior of keywords based on their existence.
To get solaris_7.0 or 7.0 (depending on whether platform exists), specify:
%{platform:-}%{platform:+_}7.0
The baseline command supports these subcommands.