Versioning
From AlfrescoWiki
Back to Main Page > Specification
[edit] Note
Alfresco is moving to a more Subversion-like versioning system soon. See the section on versioned directories for more details.
[edit] General requirements
The following is a list of the general requirements for versioning within our repository:
- Versioning should be an optional feature of the repository which can be 'installed' as a packaged feature with all the required code and definitions encapsulated within.
- Standard versioning functionality should be supported (create, get, restore, revert, etc).
- A simple public API should be available.
- The implementation of the underlying version storage mechanism should be componentised such that it can be changed with minimum impact.
[edit] The versionable aspect
In order to make a node versionable the versionable aspect must be applied, either at runtime or in the nodes type defintion.
The versionable aspect contains information about the current version that the node relates to and is required by the version service when working with a node.
[edit] The version service
The version service provides the main interface to access the version capabilities of the repository.
The version service API hides the underlying version storage mechanism and provides a number of well defined version operations.
These include:
- createVersion - this creates a new version of the referenced node which is placed at the end of the appropriate version history. If the node has no version history then one is created and this version is considered to be the initial version.
- getVersionHistory - this gets the version history that relates to the node referenced.
- deleteVersionHistory - this deletes the version history for a versioned node.
- getCurrentVersion - gets the current version for a referenced node.
- revert - reverts the state of a referenced node to that of a previous node.
- restore - restores a previously deleted node from a version in its version history.
[edit] Version meta-data, version numbers and version labels
Meta-data can be specified when creating a new version. This information is stored in the version store against the created version.
The meta-data is made up of names and values and can contain anything the user application requires. The meta-data can later be retrieved from the Version object.
Typical version meta data set by the user application could be a description of the version, the nature of the change, the importance of the change, etc.
In addition to the meta-data set by the user application there is some system meta-data that is also available.
Most notably each version has a version number. This version number is allocated on a sequential basis and follows a similar strategy to CVS version numbering. If many nodes are versioned together then they will all receive the same internal version number.
Generally this version number is only used internally, it is the version label that used publicly to identify the version.
The version label is calculated from the version number and gives, within the scope of the version history, a unique label for the version. It is this label that is placed in the versionable aspect to indicate the related current version for a node.
The generation of the version label can be customized by creating a version label policy behaviour and registering it in place of the default version label policy. This gives applications flexability to determine their own version labeling policies.
The default version label policy uses 1.1, 1.2, style of progressive version labels, moving to 2.0 if the version is considered to be a major change. This is indicated in the version meta data which the version label policy has access to.
For more information on policies see <insert the URL here>
[edit] Version histories
The version history for a node can be retrieved from the version service API and is represented as a Java interface (see org.alfresco.service.cmr.version.VersionHistory)
