A version control system is responsible for managing changes to data in a repository. This can include code, websites, documents, or any other collection of information. Version control software facilitates and to some extent automates this process

It is also referred to as a revision control, source code control, or source code management system

Several versions for the same project

Different authors working on the same project (whether for code or news) need to make sure that they will not replace the current, relevant version with something that is outdated or at a lower level of development.
A particularly good example is collaborative editing on sites like Wikipedia. Originally, anyone could create or edit a page. Obviously this has changed over time. What if two people post almost simultaneously? Or if someone decides to vandalize an item?
Wikipedia software allows you to review all changes. Each page’s “history” contains links to all revisions. And unwanted changes can be undone by selecting these links. This is a (somewhat messy) form of version control. You can think of the website with its information as a repository, and specific items and their change history as a form of version control.

The repository: the stock of all existing versions

The repository will contain each version of this code (and code from other projects) with a timestamp for each version. These internal revisions will be recorded and assigned a version number which can be incremented multiple times per day. Once the software is deployed, it is assigned a version version number, which is subject to less frequent changes.
If an issue is discovered, it may require a rollback to the current version. Usually, it is replaced with an earlier stable version while the bugs are eliminated.

Software manages the versions contained in the repository

Each file to be modified is extracted from the repository by an “update” request for the file and the version control software notes it. The developer works on his local copy of the file (a “working copy” or working copy) and, when done, will check it back into the repository (a “commit”).

How to resolve editing conflicts

We mentioned editing conflicts earlier. How are these problems resolved by the software? Usually these methods are used:
• Atomic validation applies all changes in a single operation and rolls back on failure
• Locking limits editing of the file to one person at a time
• Merge verifies that the changes are in different parts of the file and are not in conflict. In the event of a conflict, the software will keep the modified files and send an alert to the development team.
• Manual resolution is when the development team decides which version to keep and can manually edit the file to reflect this.

We have already mentioned the versions. For these, there must be an agreed standard for release versions.

Take the example of IBM for their server software, AIX 7.2.4. AIX is the name of the operating system, 7 is the major version, 2 is the minor version, and 4 is the build (or re-compilation of the software).

There may be following fields that label build revisions, fixes, service packs, and the like, but in general the format is always top level to bottom. For most versions, changing the major version indicates that backward compatibility has been compromised.

This allows anyone to quickly identify if the new version will perform differently from the old one.
In the next episode of this article, I’ll compare several versioning tools.

Source: GBNEWS.CH

This is not in any case a call for the investment