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 represents a significant milestone in the history of a File/Item and its related children. The collection of files affected in a revision is considered a revision level, which is stored as part of the assigned revision label. A revision level can be stored and retrieved, ensuring that a document, Item, and related files associated with that revision are preserved. 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.
If a document references other files and those files are edited without bumping the revision, the referencing document will consume the edits. For example:
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 in 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.
Let's take a simple example where assembly is at Rev A and part is at Rev B.
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 bias indicates that released data should take priority over non-released data. It shows the latest file's version in the used revision. This option can be turned off.
Here is an example where we have an assembly and part both at Rev A.
Let's see the Uses tab. The Uses tab lists the files used in the current model.
Click the view button /
to toggle between released/non-released bias. Note that the view button is for viewing only; it doesn't change the state of the file/component.
The Latest represents the latest revision/version that the parent is linked to. The intent is to display the latest/version of every component associated with the parent. However, it does not necessarily mean that the parent is currently using that version.
The Released refers to the released version. The intent is to display the released version that is consumed.
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.