Revision control

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

Version control is a form of variant management; there different dialects or even different modal certain variations are possible. For version control systems, the abbreviation VCS (Version Control System) is in use.

  • 4.1 Modify Write Lock
  • 4.2 Copy Modify Merge

Main tasks

  • Logging of changes: It can always be traced, who has changed what when.
  • Restoration of old stands of individual files: Thus can be undone accidental changes at any time.
  • Archiving of the individual states of a project: This makes it possible at any time to access all versions.
  • Coordination of concurrency of multiple developers on the files.
  • Simultaneous development of multiple development branches (English Branches) of a project.

Terminology

A Branch to German branch is a fork of another version, so that different versions can be developed in parallel. Changes can be included here from one branch again into another, which is then merge as merging, to German, respectively. Often the main development branch is called trunk (eg Subversion) or master ( eg Git) respectively. Branches can be created, or else to have experimental versions for development branches for different operating systems or, for example, for new major versions of software. Forks are usually branches. A certain level can also be marked with a tag ( an arbitrary identifier ).

Operation

Thus, the used programs such as text editors or compilers with the repository (English container, storage place ) dropped files can work, it is necessary that every developer is the current (or older ) status of the project in the form of a directory tree can produce from conventional files. Such a tree is called a working copy. An important part of version management system is a program that is able to synchronize working copy to the repository data. Transferring a version from the repository into the working copy is called checkout, checkout or update, while the reverse transfer check-in, check in or commit is called. Such programs are either command-line oriented, run with a graphical user interface or as a plug-in for integrated development environments. Often several of these different means of access are provided optionally.

There are three kinds of versioning, the oldest works locally, so only on one computer, the next generation worked with a central archive and the latest generation works distributed, ie no central archive. Common to all is that the version management software case usually only the differences between two versions stored to save space. Most systems use this to their own file format or database. This allows a large number of versions to be archived. By this storage format but can be accessed only with the software of the version control system to the data, which reconstructs the desired version directly on a fetch from the archived versions.

Local version management

In the local version control only a single file is often versioned, this variant has been implemented with tools such as SCCS and RCS. You can still find use in office applications that store versions of a document in the file of the document itself. Even in technical drawings versions are managed, for example by a change in the index.

Center Version Management

This type is designed as a client - server system so that access to a repository can also be done over the network. Through a rights management system will ensure that only authorized individuals can create new versions in the archive. The history here is only available in the repository. This concept was taken from the open source project, the Concurrent Versions System (CVS) popular with Subversion ( SVN) re-implemented and used by many commercial vendors.

Distributed version control

The distributed version control ( DVCS, distributed VCS) does not use a central repository more. Everyone who works at the managed project has its own repository, and can reconcile this with any other repository. The version history is distributed by the same way. Changes can be tracked locally, without having to connect to a server.

In contrast to the centralized version control, it is not a conflict when multiple users edit the same version of a file. The conflicting versions initially exist in parallel and can be changed. You can later be merged into a new version. This creates a directed acyclic graph ( Polyhierarchie ) instead of a chain of versions. In practice, most individual features or groups of features are in use in software development developed in separate versions and checks them for larger projects of persons with an integrator role and merged.

Due to the system provide distributed version control systems, no locks. Since due to the higher access speed, the granularity of the stored changes can be much smaller, they can provide very powerful, largely automatic merge mechanisms.

A subspecies of the versioning offer easier patch management systems that feed the changes in only one direction in production systems.

Although conceptually not essential, there is usually an official repository to distributed version management scenarios. The official repository is cloned from new project participants at the beginning of their work, ie copied to the local system. In the case of open source software, the official repository is often stored in a web-based hosting service like GitHub or Bitbucket.

Concepts

Lock Modify Write

This method of operation of a version control system is also known as Lock Unlock Modify. The underlying philosophy is called pessimistic version management. Individual files must be locked from modification by the user and enabled again after the change. While they are locked, the system prevents changes by other users. The advantage of this concept is that no merging versions is necessary because just getting a developer can change a file. The disadvantage is that you have to wait sometimes for the release of a document to introduce a separate change. It should be noted that binaries require (as opposed to source code files ) usually this way of working because the version control system distributed changes can not synchronize automatically. The oldest representatives of this operation is the Revision Control System, is also known Visual SourceSafe. Distributed version control systems do not know due to the system this way of working.

Copy Modify Merge

Such a system allows simultaneous changes to multiple users on a file. Subsequently, these changes are automatically or manually merged ( Merge). Thus, the work of the developer is much easier, as changes need not be announced in advance. Especially when many developers working at remote locations, as is often the case with open source projects, this allows only work efficiently, since no direct contact between the developers is needed. The problem with this system is a binary file, because these often can not be merged automatically, if no suitable tool is available. Some members of this genus, therefore, also support alternatively, the lock- modify-write concept for specific files.

The underlying philosophy is called the optimistic version management and is designed to overcome the weaknesses of the pessimistic version management. All modern centralized and distributed systems implement this method.

Object -based versioning

About the limit of abspeichernden medium, the file goes beyond the object -based versioning. Objects are created in the computer science as so-called instances, ie forms a schema. These can also be stored versioned. Version control, which stores the different versions of objects must be able to deal with the corresponding object types. For the reason such a system reads not only the file and checks them for changes, but can interpret the semantics contained therein. Usually, objects are not file-based, but stored in a database. Product data management systems (PDM ) systems manage their data according to this principle.

Examples

The following table contains some version control systems as examples of the different expression types.

  • RCS
  • CVS
  • Subversion ( SVN)
  • Alienbrain
  • Perforce
  • Team Foundation Server
  • Visual SourceSafe
  • ClearCase
  • IBM Rational Synergy
  • PTC Integrity
  • SAP Design Time Repository ( DTR)
295991
de