Today I tried to remember the good practice that performed when modifying configuration files, and how often does. I think we’ve all seen the type files with suffixes .old, .orig, .bkp,  .someDate to serve as a pseudo-backup important configuration file.

I will not come to assess whether this method is good or bad, because we should evaluate other factors such as whether the machine is managed by various admins, if a critical server, if it really is documented that nomenclature, etc …

But if I want to mention, and give an example of a methodology that if it is standard, and there is a very high probability of finding it in almost any GNU / Linux: RCS utils.With this system, we have a version control with all its benefits applied to a single file without creating or configure anything extra (or repositories, or demons, or service units), only installing the required package rcs. It is rare that is not installed.

This information has been obtained from RCS Intro – http://www.daemon-systems.org/man/rcsintro.1.html

What operations are usually performed more frequently in a version control system?

• Create new files
• Modify existing file
• Locked to prevent concurrent modifications
• Control versions and add comments to see at a glance this Changelog
• Test differences between versions
• Retrieve all versions
• Control who and when to file an amendment during their life

Based on this short list, put the two commands that allow you to perform them:

co and ci

Read on to see examples …

Examples:

$ vi file1 # edit and save changes

$ ci-u file 1 # With this we create the first review, and we asked to enter a comment with a brief summary of the contents of the file

From this moment, we have two files like: file1 and file1, v. This second file will contain the entire version control is not necessary any more. The -u parameter is not to erase the local copy. In subsequent ci we do, we are asked to enter a comment, but in this case will be referred to the changes we have made.

$ co -l file1 # Perform a checkout, that is get a copy of the latest revision of the file, and also the block by the -l. This means that we can edit now.

From this moment, these two commands are the most frequently used to use RCS on specific file. Then we can use parameters like -r1.24 to tell the review with which to save the file, or obtain the hotfix.

We may use rcsdiff to see the differences between two revisions, or the rlog command to see the whole evolution of the file with your comments. There are many more options, and I got sent to the link in the article that you may prove the most commonly adjusted to you.