Version management

from Wikipedia, the free encyclopedia

A version control is a system that is used to record changes to documents or files. All versions are saved in an archive with a time stamp and user ID and can be restored later. Version management systems are typically used in software development to manage source texts . Version management is also used for office applications or content management systems .

Another example is Wikipedia , where the software creates a new version every time an article is changed. In Wikipedia, all versions form a chain in which the last version is valid; no variants are provided. Since the basic information such as author and time is recorded for each version change, it is possible to track exactly who changed what and when. If necessary - for example in the case of accidental changes - you can revert to an earlier version.

Version management is a form of variant management ; There different language variants or modally differently determined variants are possible. The abbreviation VCS ( Version Control System ) is common for version management systems .

Main tasks

  • Logging of changes: It can be traced at any time who has changed what and when.
  • Restoration of old versions of individual files: In this way, accidental changes can be undone at any time.
  • Archiving of the individual status of a project: This means that all versions can be accessed at any time.
  • Coordination of the joint access of several developers to the files.
  • Simultaneous development of several development branches (Engl. Branch ) of a project which does not match the spin-off of another project (Engl. Fork ) may be confused.


A Branch to German branch is a branch of another version so that different versions can be developed in parallel in the same project. Changes can flow from one branch into another, which is referred to as merging . Often the main development branch is referred to as trunk (e.g. with Subversion ) or master (e.g. with Git ). Branches can be created, for example, for new major versions of software or for development branches for different operating systems or to have experimental versions. If a branch is created in a new, independent version control, it is called a fork . A specific status can also be marked with a tag (a freely selectable identifier).


So that the programs used, such as B. text editors or compilers can work with the files stored in the repository , it is necessary that every developer can generate the current (or an older) status of the project in the form of a directory tree from conventional files. Such a directory tree is known as a working copy. An important part of the version control system is a program that is able to synchronize this working copy with the data in the repository. Pushing a version from the repository to the working copy is called a checkout , checkout , or update , while the reverse transfer is called check-in , check -in , or commit . Such programs are either command line oriented , run with a graphical user interface or as a plug-in for integrated software development environments . Often, several of these different access options are optionally provided.

There are three types of version management: the oldest works locally, i.e. only on one computer, the next generation works with a central archive and the latest generation works in a distributed manner, i.e. without a central archive. What they all have in common is that the version management software usually only saves the differences between two versions in order to save storage space. Most systems use their own file format or database for this . This allows a large number of versions to be archived. Due to this storage format, however, the data can only be accessed with the software of the version management system, which reconstructs the desired version directly from the archived versions when called up.

Local version management

With local version management, only a single file is versioned; this variant was implemented using tools such as SCCS and RCS . It is still used today in office applications that store versions of a document in the file of the document itself. Versions are also managed in technical drawings , for example using a change index.

Central version management

This type is designed as a client-server system so that a repository can also be accessed via the network. Through a rights management is ensured that only authorized persons can create new versions in the archive. The version history is only available in the repository. This concept was popularized by the open source Concurrent Versions System (CVS) project , re-implemented with Subversion (SVN) and used by many commercial providers.

Distributed versioning

The distributed version management ( DVCS , distributed VCS) no longer uses a central repository. Everyone who works on the managed project has their own repository and can synchronize this with any other repository. The version history is distributed in the same way. Changes can be tracked locally without having to establish a connection to a server.

In contrast to central version management, there is no conflict if several users change the same version of a file. The conflicting versions initially exist in parallel and can be changed further. They can later be merged into a new version. This creates a directed acyclic graph ( polyhierarchy ) instead of a chain of versions. In practice, when used in software development, individual features or groups of features are usually developed in separate versions and these are checked and merged in larger projects by people with an integrator role.

Due to the system, distributed version management does not offer any locks. Since the granularity of the saved changes can be much smaller due to the higher access speed, they can provide very powerful, largely automatic merge mechanisms.

A sub-type of version management is offered by simpler patch management systems that only feed changes in one direction into productive systems.

Although conceptually not absolutely necessary, an official repository usually exists in distributed version control scenarios. The official repository is cloned by new project participants at the start of their work; H. copied to the local system.


Lock Modify Write

This way of working of a version management system is also known as Lock Modify Unlock. The underlying philosophy is called pessimistic versioning . Individual files must be locked by the user before a change and released again after the change has been completed. While they are locked, the system prevents changes by other users. The advantage of this concept is that there is no need to merge versions, as only one developer can change a file at a time. The disadvantage is that you may have to wait for a document to be approved before you can make your own change. It should be noted that binary files (as opposed to source code files) usually require this mode of operation, since the version control system cannot automatically synchronize distributed changes. The oldest representative of this working method is the Revision Control System , just as well known is Visual SourceSafe . Due to the nature of the system, distributed version management systems do not know this way of working.

Copy Modify Merge

Such a system allows simultaneous changes to a file by several users. These changes are then merged automatically or manually ( merge ). This makes the developer's work much easier, as changes do not have to be announced in advance. In particular, when many developers work in separate locations, as is often the case with open source projects, for example, this enables efficient work because no direct contact between the developers is required. Binary files are problematic with this system because they often cannot be automatically merged unless a suitable tool is available. Some representatives of this type therefore also support the lock-modify-write concept for certain files as an alternative.

The underlying philosophy is called optimistic versioning and is designed to address the weaknesses of pessimistic versioning. All modern central and distributed systems implement this procedure.

Object-based versioning

Object-based versioning goes beyond the limits of the storage medium, the file . In computer science, objects are created as so-called instances , i.e. versions of a schema. These can also be saved in versioned form. The version management, which saves the different object versions, must be able to handle the corresponding object types. For this reason, such a system not only reads the file and checks it for changes, but can also interpret the semantics it contains . Usually, objects are then not file-based, but stored in a database. Product data management systems (PDM systems) manage your data according to this principle.


The following table contains some version management systems as examples for the various types of expression.

Open source systems Proprietary Systems
Central systems
Distributed Systems

See also

Web links