This article explains the basics of configuration management.
Configuration management is used to keep track of changes made on programs or documents.
In this article are explained the following concepts:
the repository and the local working
modifying a file, and incrementing the version number
The repository is a special place where all files are kept.
Changes are recorded every time a file is modified.
Every change on a file yields a new version of the file. It is possible to get any previous version.
The user cannot modify the files directly in the repository.
The user can work only in a local directory.
In this example, the file has been created with version 1.1 ("v" means "version"), and has been modified twice (v1.2 and v1.3).
Usually there is not one single file in the repository, but many files.
Tags are used to indicate which file versions are coherent together.
In this example, all the files tagged with Release B are coherent together.
The user can get them as a whole.
How could some versions of some files of the same project be incoherent ?
For example, suppose you have a program v1.1 and its user guide v1.1.
When the program evolves to a new version v1.2 with a new functionality, the old user guide v1.1 is no more coherent with the program v1.2, because the old user guide gives no information on the new functionality.
A branch is used to make modifications on a previous version (not on the latest one).
Here the file vEE.0 is exactly the same as file v1.1. It is just used to start the EE branch.
Why would I need to modify a previous version ?
Suppose you have sold your file v1.2 to a big company (this example follows the previous drawing).
Then you have improved your file with new functionalities (file v1.3).
You would like to sell your file v1.3 to the big company, but a bug has been discovered in your file v1.2, and you must provide support to the big company.
If you correct the bug in the file v1.3 (the latest) and give it to the big company, you shall not be able to sell file v1.3 normally.
Then you need to correct the bug in a branch starting from file v1.2.
In our previous example (on the drawing), the branch is called EE. You can deliver file vEE.1 with the correction of the bug.
And all subsequent corrections will be in file vEE.2, file vEE.3, etc...
