Introduction to VersionVault Express concepts
This article will describe how VersionVault Express manages versioned assets using the capabilities of VersionVault Unified Change Management (UCM).
VersionVault Express uses UCM to implement a version control system packaged in a virtual appliance. Each VersionVault Express instance hosts a set of VersionVault Express projects, each of which has its own source repository, a Versioned Object Base (VOB). The VOB stores meta-data about the project along with the versioned contents of files/directories/symbolic links managed inside the project. Membership in the project is recorded in the VOB’s access control lists, which the project owner manages. (See the reference links at the end of this article for an introduction to the roles supported by VersionVault Express.)
VOBs, Projects, and Components
Each VersionVault Express project is built on a single VOB containing a single UCM Project, used to organize streams and their contents, and a single UCM component, used to store the versioned file and directory elements. These are created automatically during VersionVault Express project creation. In most cases you won’t ever need to explicitly manage these UCM objects.
The UCM project contains multiple UCM streams, where the project members manage their versioned objects. Developers can isolate their work on their own streams until they are ready to merge their work with work from other developers.
Each project is independent and self-contained. If you need to coordinate between multiple projects, you’ll do that yourself outside the scope of VersionVault Express.
Streams
A UCM stream manages a branch of the versioned data. The top-level stream of the project is the integration stream. This stream will primarily be managed by an account in the Builder role. Developers don’t usually check in changes directly to this stream—they normally use developer streams as a place to make their changes and verify them.
Each developer gets a developer stream when they join the project. Their stream is a child of the integration stream. They can deliver changes to the integration stream, making the changes available to other developers, and rebase their stream, to sync up their stream to incorporate the latest changes from other developers’ deliveries.
Baselines
The code base evolves over time as developers check in code to each stream. The project’s builder user typically creates a baseline on the integration stream after certain operations such as a completed delivery. The baseline represents a snapshot in time of the state of a stream, referring to one version of each controlled element in the VOB. Over time you create a series of baselines capturing the history of the stream.
Each stream has two distinguished baselines: the recommended baseline and the foundation baseline. The builder can designate a baseline created in the stream as the recommended baseline, usually as an indication that the code has been built and tested satisfactorily. The recommended baseline is offered as a default choice for the rebase operation for child streams, and as the foundation baseline for any new child streams, such as a new developer’s stream or a feature stream.
VersionVault Express streams are arranged in a hierarchy—we’ve already seen that the project integration stream is the parent of all the “standard” developer streams. But if you need some additional isolation and a way for developers to collaborate without disturbing the main integration stream, you can create a “feature stream” (or a hierarchical tree of such streams). In a single level of feature stream you’d have this hierarchy:
- project integration stream
- feature stream
- developer#1 feature stream
- developer#2 feature stream
- Non-feature developer#3 stream
- feature stream
The builder would manage baselines in the feature stream, while developers working on the feature would rebase from and deliver to the feature stream. At some point when the feature is in good shape, the builder or lead developer would deliver from the feature stream to the project integration stream. Developers not working on that feature can work on their own developer stream parallel to the feature stream.
If you need more complex merging patterns than the strict parent/child delivery/rebase model in VersionVault Express, you can use the VersionVault Explorer to manage individual activities and merges between streams, or you can upgrade to full VersionVault for even more flexibility.
Deliver and Rebase
Deliver and rebase follow the stream hierarchy: you rebase to pick up changes from a new baseline in the parent stream, and you deliver to merge your stream’s changes into the parent stream.
Activities
Within a stream, you can check out and check in versions of files and directories. Since these streams are typically used for continuing development, each change in a stream must be linked to a UCM activity to track a set of related changes. VersionVault Express uses UCM activities to link together the change set of related versions, just like full VersionVault. The developer creates an activity to manage each logical change, then checks out/checks in/adds files while they have the activity set as the current activity. When they are ready to merge code to the parent stream, they can deliver just a selection of activities, or all the activities with unmerged changes.
Summary
You’ve learned that VersionVault Express uses UCM projects, components, streams, baselines, and activities to manage changes to elements. Streams are arranged in a hierarchy, which developers follow when delivering changes so others can get them and rebasing to get changes from their colleagues. Baselines mark the evolution of versions in a stream during the development cycle of a project. Activities collect versions of multiple elements into a coherent related change set.
For more info
There’s lots more to VersionVault Express, built on the power of VersionVault. Here are some additional resources to learn more:
- See the product help:
