A versioning system records changes to documents or files and saves them. All versions are captured with a timestamp, user ID, and can be restored at any time. Usually used in software development to manage source code, version control systems are also common among office applications or content management systems. Version control, or variant management, is a system that allows for different versions to be created. For example, there may be language variants or modal variants. Version control systems have often been abbreviated as VCS.
In a basic system of any wiki, whenever somebody edits an article, the software creates a new version and links it to all previous versions (which form a chain). All changes are recorded – down to the author and when they were made – so if something goes wrong you can revert back to an earlier version.
- Changes are logged: You will always know who made what change and when.
- Restore of previous files: Thus, any changes can be undone at any time.
- Archiving of individual project versions: Having this function makes it possible to access all your individual project versions at any time.
Commonly used Types in Software Development
In order for developers to edit files, they need to have a working copy of the project. Every developer’s working copy needs to be updated with content from the repository regularly. The process of transferring a file in the repository to a developer’s working copy is called checking out or updating their working copy, while transferring it back would be a check-in or commit. In some cases, several different access options are available for developers such as command line oriented programs, graphical user interfaces, or as plugins for integrated development environments.
There are three types of version control, the first only works locally, i.e. on one computer. But the newer generations work with a central archive and operate without one. What they all share is that software usually only stores the differences between two versions in order to save disk space. Most systems use their own file format or database for that. This allows a large number of versions to be archived. However, this storage format means that the data can only be accessed with the software of the version control system, which reconstructs the desired version directly from archived versions when it’s retrieved.
In a local version, you might only be managing one file. This is what SCCS and RCS were designed for. It’s still used today in office applications for storing versions of documents in the files that contain them. Even technical drawings are kept up to date with changes. For example, the change index manages versions accordingly.
There are three different types of version control systems – centralized, distributed and collaborative. Centralized VCSs have one central location with a single administrator, while distributed VCSs allow multiple users to share the same content. These two models are the most commonly used for professional code development. When a repository is shared among collaborators, it’s said to be in a collaborative VCS. It’s important to note that access to the repository can be done over the network via one user who has “write” permission, or by any number of users. Rights management ensures that only authorized persons can make changes to the repository (e.g., add new versions). The history is only available within this local copy of the repository. This model was popularized by open source projects like Concurrent Versions System (CVS) and Subversion (SVN).
With DVCS, there is no longer a need to use a central repository. Every developer has their own repository and can synchronize it with any other repository on the network. The version history is thus distributed in the same way. Changes can be tracked individually without having to connect to a centralized server.
With distributed version control systems, there is no conflict when two or more people try to change the same file. The conflicting versions exist in parallel and can be changed further. They can later be merged into a new version, creating a directed acyclic graph (polyhierarchy) instead of a linear list of changes. In software development, individual features or groups of features are developed in separate branches and reviewed and merged in larger projects by people with an integrator role.