Since release 5.5, codeBeamer support document and wiki baselining.
Baselines in codeBeamer capture the state of your digital content in a moment, pretty much like tags mark a particular state of the source code in a Version Control System.
When you create a new named baseline, a snapshot of your requirements, tracker items, wiki pages, documents, comments and attachments is saved. In the future, you can "go back in time" and browse any earlier baseline, to see how that content looked in that snapshot. Baselines can also be compared to find out what content has been changed between two snapshots, when exactly and by whom.
Baselines are not storage-wasting physical copies of content. They are rather references to the current versions of the content in the given moment.
Baselines are useful for audit purposes, including deviation against a previous baseline, certification for an approval, comparison to another baseline, maintaining wiki pages for multiple product releases, or all of these. Read more about the applications of baselining in Wikipedia.
A baseline is a lightweight read-only directory/index of all documents and their respective revision (at the time of baseline creation) in a document tree branch, including the document hierarchy/structure.
But what makes codeBeamer baselines such a unique/powerful feature is their support for cross references in Wiki documents.
If a baseline contains Wiki documents, it also stores references to all documents and their respective revision (at the time of baseline creation) referenced/included by the contained Wiki documents, and also recursively to documents referenced/included by the referenced documents.
As a result, when browsing Wiki documents from a CodeBeamer baseline, all references and inclusion are consistently resolved to the respective revision at the time of baseline creation, even if the target documents have been modified or even deleted in the meantime.
For example: Baseline "Release 1.0" of directory "Deliverables"
Figure: Wiki Inclusion and References Resolved to a Revision
A baseline is lightweight because it only stores references to specific document revisions which already exist: it does not copy any document data.
The same revision of a document can be referenced by any number of baselines at the same time.
Document revisions referenced in baselines will not be deleted unless all baselines holding references are deleted, even if you delete the document, the document tree branch where the document resides, or the project containing the document.
Baselines are immutable: you cannot add, edit or remove items after baseline creation.
Read permission to all items (document revisions) in a baseline is solely controlled via the baseline. You cannot define permissions for individual items.
Baselines appear as a special type of folder/directory in the document tree and are also accessible via WebDAV.
By default, new baselines reside in the same directory where they were created which has these effects:
a baseline initially has the same access permissions as the source directory,
deleting the source directory (or any of its parents) also deletes all baselines in the directory.
Because a baseline is a special type of directory, you can move the baseline (as a whole) to another location (via Cut and Paste) or even to another project.
Figure: Moving a Baseline You must login to see this link. Register now, if you have no user account yet.
This is especially useful if you have separated development/production and distribution into two projects. You do all development and document editing in the private development project. When you have finished a new release, create a new baseline named according to the release and publish (move) it to the public distribution project.
For customers to access the new release documentation, they only need permission for the release/baseline in the public distribution project. If your development also includes source code, you should create a VCS tag/support branch in parallel.
There is absolutely no risk of customers (accidentally or intentionally) tampering with the released documents. It is neither necessary nor advisable to grant customers access to the private development project.
As soon as you have created the release baseline you can start working on the next release, with absolutely no risk of modifications leaking through to the public.
You can also copy (parts of) baselines, but this is not a lightweight operation. When you copy a directory, any baselines residing in that directory (or its subdirectories) will not be copied recursively. This was intentionally designed this way. To copy a baseline select it explicitly.
To create a baseline click on the Baselines menu in the main menu bar, and click on the New Baselines link:
Specify the following attributes in the opened dialog:
Name : the baseline's name, this property is mandatory and it must be unique
Description: a short description for the baseline
Signature: the baseline is signed by the current user if the user's password is given in this textbox
Click on the selected baseline's name on the baseline list:
Then the baseline's content shown in the document management view:
Edit baseline's properties
Click on the selected baseline's edit button:
Then the baseline properties opens in the default properties view:
Open baseline properties page, click on more menu and select the lock menu item:
If a baseline is locked it cannot be edited until someone (who has the right permissions) unlocks it.
Click on the selected baseline's delete button:
To select baselines use the two "SELECT BUTTON TO COMPARE" buttons at the top of the page:
Select the baseline by clicking it's name in the overlay:
Press the "Compare Selected Baselines" button:
The opened view shows the differences between the two baselines:
The differences between the selected baselines are separated into categories. Every category has a tab in the result view. The detailed modifications can be viewed by opening the category tabs, for example the work items: