It is important to understand how revisions work before performing any revise events on files.
With revisions, you can label a significant milestone or set of changes to a document and its related files. The label itself is the revision and the collection of files affected in that revision are considered a revision level. A revision level can be retrieved later so that a document and the version of the related files associated with that particular revision are preserved.
Review the following sections to learn more about revisions and how they work within the Vault environment.
A version is an iteration of a document and its meta-data that has been saved to the vault.
A revision is a collection of versions with a common label. This label usually represents a significant milestone in the work done to achieve a desired change. The revision is usually marked with a single character, such as A or B. A revision is created with the Revise command. Revisions can also be automatically generated through a Lifecycle State change.
When a revision is downloaded from a vault, only one version within that revision is used to represent the revision. If lifecycles are not used, then the version is always the latest within that revision.
When using documents that are related to each other, such as an assembly and its referenced components, a relationship is created between the specific revisions of those documents. When an assembly is checked into a vault, the revision of each of its components is recorded so that when that revision is recalled, each related document is retrieved using the recorded revision.
Editing a referenced file without creating a new revision
If a document references other files and those files are edited without bumping the revision, the referencing document will consume the edits. For example:
Editing a referenced file after creating a new revision
If a document references other files and a new revision is created for one of those files, the referencing document still maintains a relationship with the original revision. For example:
When a version within a revision is marked as released, it is given priority over newer versions and will represent the revision. This prioritization is known as a released bias and is an option that can be turned off in several of the dialogs.
The "Latest Approver" property describes the user who approved/released the last revision of a document. If an Administrator changed some properties in Vault for the released file, the "Latest Approver" displays a user that released the version.
The "Latest Release Date" property describes the date and time when the last revision of a document was released.
Released biased is an option in several of the dialogs indicating that released data should take priority over non-released data. This option can be turned off.
The leading version, or tip version, is always the latest version of a file, even if Released Bias is enabled.
The leading revision , or tip revision, is always the latest version of the latest revision of a file, even if Released Bias is enabled.
When used in combination with lifecycles, revisions can be generated automatically after a predefined event occurs. For example, the administrator can configure it so that when a file is moved from a work in progress to review state, the system automatically creates a new revision of the file.
A quick change is an edit made to a file without creating a new revision. Quick changes are invoked by setting a document's state to Quick Change and then modifying the file.