Version management
| Table of contents |
A version history exists for all project data in a FirstSpirit project which shows how the data has been changed over time. The primary objective is the most continuous possible traceability of all changes and the possibility of resetting these at any time.
Versioning and historization
First, let us consider the basic objects of a content management system, for example, a medium, an individual page or a section. A new version of the object is created for each change made to such an object by the editor. Thus, an object has a version history on the basis of which it is possible to trace which changes were made by which persons over time.
The version history of the individual objects is not sufficient to ensure complete traceability of all changes as the individual basic objects are grouped together within the content management system to form more complex structures. In FirstSpirit, for example, pages are compiled from individual sections and are combined in the Site Store to form a navigation. Changes to these structural aspects must therefore also be part of the versioning. So the versioning of the basic objects and the structural aspects gives a versioned description of the whole system status, which enables changes to be traced.
A further aspect which must also be taken into account within the scope of versioning is the implementation of procedures for the approval and release of changes. A release procedure is usually implemented via an appropriately professional workflow. At the technical level, when a change is released a specific version of an object is labeled as being “released”.
Repositories and revisions
All the information required is stored in a FirstSpirit repository, a central place in which the data structures (media, pages, templates, etc.) required by the content management system are managed. Each FirstSpirit project has its own self-contained repository. A special method of managing the chronological development of data is used in the FirstSpirit repository, which is known as “revision management”.
A revision can be thought of as a kind of “snapshot” of the whole repository at a specific point in time. Unlike a version, which usually only relates to a single object, the complete state of all objects is described in a revision.
Revisions are described by consecutive numbering, whereby there is always precisely one current revision for the whole repository. When a repository is edited, all changes made in a logical context (however it is defined) are linked with a new revision number. The revision number results from the last current revision number of the whole repository increased by one. All unchanged objects retain their old revision numbers. If an object is changed, it is not overwritten in the repository, but rather inserted as a new object (with a higher revision number).
A version history of individual objects can be opened at defined objects of a project using the context menu.
Supported objects
The version history is available for the following stores and objects: