Pour lire la version française de cet article, cliquez ici.
A version control system is responsible for managing data changes in a repository. This can include code, websites, documents, or any other collection of information.
Version control systems are also known as revision control, source control, or source code management systems.
Different authors working on the same project (whether that be for code or information) need to ensure that they will not replace the current, relevant version with something that is out of date or at a lower development level.
A good example is the collaborative editing on sites such as Wikipedia: originally anyone could create or edit a page. What if two people publish almost simultaneously? Or someone decides to vandalise an article?
The Wikipedia software allows the review of all changes. Each page’s “history” has links to all of the revisions and unwelcome changes can be undone by selecting those links. This is a (somewhat disordered) form of version control. One can consider the website with its information as the repository, and specific articles and their history of edits as a form of versioning.
For development teams, it is essential that they do not encounter edit conflicts.
Development teams will run into this sort of problem on a regular basis if more than one person is working on a piece of code (and sometimes, depending on the coder, if only one person is working on the code). The repository will contain each version of that code (and the code of other projects) with a timestamp for each version. These internal revisions will be logged and assigned a version number that may be incremented many times a day. Once the software is rolled out, it is assigned a release version number, which is subject to less frequent changes.
If a problem is discovered, this may necessitate a roll-back of the current version. Usually, it will be replaced by a stable prior version while the bugs are being eliminated.
Each file to be modified is checked out of the repository (a request for “update” of the file) and the versioning software notes this. The developer works on their local copy of the file (a “working copy”) and when finished, checks it back into the repository (a “commit”). Modern versioning software allows for distributed local repositories with a central repository, pushing updated files down to the local repositories and pulling updated files back, with the central repository doing the same, like so:
If there are multiple developers working on the same code, things can become more difficult. This leads to the next stage.
A trunk is the base of the project: developers will branch off from the trunk, make their modifications, test for functionality and stability, and then merge that branch into the trunk (maybe creating a tag for the new stable version that can be reverted to). Good team communication reduces problems.
How are edit conflicts resolved by the software? Generally, these methods are used:
We have mentioned releases before. For these, there must be an agreed-upon standard for release versions. Here, we see an example from IBM for their AIX server software, AIX 7.2.4. AIX is the name of the operating system,7 is the major release version, 2 is the minor release version and 4 is the build.
There can be subsequent fields that label revisions to the build, patches, service packs, and similar. In general, though, the format is always from the highest level downwards.
For most versions, changing the major release version indicates that backward compatibility has been compromised. This allows anyone to rapidly identify if the new version will work differently from the old one.
In the next article, I will look at different version control software used to simplify, and to some extent, automate the processes described here.
Further reading:
