Showing baseline information

About this task

This subcommand shows general information about the specified baselines.

ccm baseline -sh|-show (i|info|information) -f|-format format 
             [-nf|-noformat]
             ([-ch|-column_header] | [-nch|-nocolumn_header]) 
             [-sep|-separator separator] baseline_spec...
ccm baseline -sh|-show (i|info|information) baseline_spec...
baseline_spec...
Specifies the baseline_name or Query selection set reference form to be used where a baseline name is allowed. For more information, see Baseline specification.
-ch|-column_header
Specifies to use a column header in the output format. See sc_r_h_unnumbered_fs.html#__wp819979 for details.
-f|-format format
Specifies the command output format. See sc_r_h_unnumbered_fs.html#__wp826148 for details.
-nch|-nocolumn_header
Specifies not to use a column header in the output format. See sc_r_h_unnumbered_fs.html#__wp827851 for details.
-nf|-noformat
Specifies not to use column alignment. See sc_r_h_unnumbered_fs.html#__wp826095 for details.
-sep|-separator separator
Used only with the sc_r_h_unnumbered_fs.html#__wp826148 option. Specifies a different separator character. See sc_r_h_unnumbered_fs.html#__wp826071 for details.

Description and uses

About this task

A baseline is a set of projects and tasks used to represent your data at a specific point in time. A baseline has many uses. When you perform an update, Rational Synergy uses a baseline 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 Change, you can use baselines to generate change request reports.

Typically, a build manager creates a baseline; a developer doesn’t need to create a baseline because he doesn’t make his builds available to other users.

You might find it useful to 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 Rational Synergy in case it is needed later to create a fix for that particular build.

Creating a baseline for each Integration Testing and System Testing build helps testers and developers to refer back to the set of changes that were used to create the build. Typically, you’ll 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.

Note: When you create a baseline, you’ll specify a list of projects to be included in the baseline. Be sure to include all related projects in your baseline so that you have a complete set for reference.

Baselines can be used by process rules to define the baseline for the projects that use that template. For example, a build manager may create a baseline named Integration Build 20040913 containing static projects toolkit-int_20040913, calculator-int_20040913, etc. The numeric designation is the date (yyyymmdd) the baseline was created.

A process rule can specify 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, if the Integration Testing process rule for the current release specified that the Integration Build 20040913 baseline should be used, a developer’s calculator-bob project would select calculator-20040913 as its baseline project.

Using baselines has these benefits:

  • Build managers have a lightweight way to save a set of projects that were successfully built and tested.
  • Process rules are more flexible; they can specify a particular baseline or the latest baseline with certain characteristics, enabling build managers to control the team process more precisely. If problems were discovered in a newer baseline, the build manager can reset the team baseline to a previous, successfully-built baseline.
  • The update operation uses the baseline to streamline which tasks are evaluated, thereby improving update performance. Only those tasks on top of the baseline are considered when computing update candidates. When a baseline is created, the set of tasks is taken from either the project grouping or from the projects themselves for the projects that update manually. In addition, the tasks from the baseline (for the project grouping) are added to the new baseline, unless the release is different.
  • Team members can compare baselines to identify which tasks were introduced in the latest baseline, or identify whether a baseline includes a particular task. This is useful for testers who need to know what features to test, as well as whether to expect a known problem to be fixed in a particular build.
  • Specify that a project should be updated to match the latest successful build.

How is a new baseline created?

Both prep-state projects and static projects may 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. Other than that, 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 this 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 to the existing version string (and also 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 existing build management projects are checked out from the new baseline projects. In addition, project histories are updated to make it 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, you must enable work area maintenance after the baseline has been 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 will fail. 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 may not have been copied to the database. In such a case, the baseline will contain what is in the database, not what is in the non-visible work area. To avoid this problem, the build manager must make sure that changes to all non-visible work areas of projects that are added to a baseline have been synchronized to the database. This must be done before adding such projects to a baseline.

Use the baseline command to:

  • Create a baseline from an existing prep hierarchy or set of hierarchies.
  • Save a baseline instead of manually populating the Tested Tasks folder in order to publish the latest tested changes to developers.
  • Show information or associated projects, objects, and tasks for a specific baseline.
  • List baselines.
  • Modify or rename a baseline
  • Release a baseline or compare two baselines.
  • Delete an existing baseline, or mark a baseline for deletion.
  • Restore a deleted baseline.

You must be working as a build manager to create or release a baseline. You must be working as 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, if 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 will be reversioned.

If the instantiated version_template for any project or product in the baseline contains characters that are not allowed in a version string, then those characters are replaced with the default version string replacement character. This is specified in the 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 will make 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, and a warning is 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 proper file permissions or disk space, 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.

  • %{keyword:-string} If keyword is set and is non-null, it expands normally; otherwise it expands to string. Note that string can be an empty string if you want to see nothing when the keyword is not found.
  • %{keyword:+string} If keyword is set and is non-null, it expands to string; otherwise it expands to the empty string (substitute nothing).

    To get solaris_7.0 or 7.0 (depending on whether platform exists), specify:

    %{platform:-}%{platform:+_}7.0

    • %{platform:-} expands to solaris if the platform exists (and was solaris); otherwise it expands to the empty string.
    • %{platform:+_} expands to _ if the platform exists; otherwise it expands to the empty string.

Feedback