Share this page
In a version control enabled project, you can create and manage Application Lifecycle Management (ALM) entities while maintaining previous versions of these entities. This includes requirements, tests, test resources, business process models, and business components.
To make changes to an entity in a version control enabled project, you must first check out the entity. When you check out an entity, ALM locks the entity, preventing other users from overwriting any changes you make. The checked out version of the entity is not visible to other users.
When you finish making changes, you check in the entity. The new version of the entity is then available to other users.
You can view all previous versions of an entity, or check out an earlier version. You can also compare two versions of an entity to view the changes between versions.
Note: Version control applies to single entities only. To maintain usability and data integrity, ALM stores previous versions of an entity without data related to relationships between entities. When an entity is checked in, only data of the individual entity is stored. The following data is not stored for versions: requirements and tests coverage, requirements traceability, and defect linkage. In addition, risk data is also not stored for previous versions of an entity.
Baselines provide a snapshot of a set of entities and the relationships between them. For details, see Baselines Overview.
You can create and manage entities in a version control enabled project. An entity checked out by the current user is displayed with an open green lock icon
. An entity checked out by another user is displayed with a red lock icon
. Grid views contain additional version control fields, such as Version Status, indicating whether the entity is checked in or checked out.
For details on ALM fields not stored under version control, see Non-versioned Fields.
For more details on working with version control, see How to Use Version Control.
The following examples demonstrate when you can use version control.
Example: Monitor changes and compare versions
Kelly, the product manager, finds that product development is being implemented differently than she had expected. She reviews the requirements for the product and discovers that some have changed. She compares the current requirements with the versions of the requirements that were agreed upon at the start of the release.
Example: Restore an earlier version
Michael, a QA tester, receives a new build of the banking application currently being developed. He starts to update the relevant tests to meet the needs of the new release. Then the development team sends out notification of a significant problem with the build. Development rolls back to the previous build. Michael decides to check out and revert back to the versions of tests that were used for the previous build and continue testing from there.
Example: Lock entities for editing
Robert, a business analyst, wants to update certain functionality for an application. To do this, he needs to update a set of requirements. He requires several days to update the requirements, and does not want anyone else to make any changes to the requirements while he is editing them. Robert checks out the relevant requirements, and starts to edit.
