non

encore faut-il disposer d'un systeme d'historisation de version...

Si on veut se passer d'un cvs/svn/bzr/... on peut toujours effectuer une journalisation « externe » : le serveur de versions est distinct du serveur réel et on commit les changement sur les deux. L'intérêt d'une journalisation externe au fichier est de garder un historique complet sans allourdir le contenu du fichier (et donc sans nuire à sa lisibilité). En général quand on lit/modifie le fichier, l'historique n'est d'absolument aucune utilité et le maintenir manuellement est particulièrement pénible et sujet à erreurs. Quand a besoin de l'historique d'un fichier, on va le demander au gestionnaire de versions. On va même plutôt lui demander directement l'information qui nous intéresse (« Quel est le crétin qui a modifié cette ligne et quand ? Qu'est-ce qu'il a pété d'autre sur ce commit ? ... »). Au final c'est bien plus efficace que de garder toutes ces méta informations dans le fichier même.

un commentaire dans le code n'est-il pas à la base d'un code lisible et renseigné ?

C'est hors sujet mais non. La base d'un code lisible est un style clair et cohérent. Si le code sans commentaire est incompréhensible, les commentaires n'aideront pas beaucoup. Voire http://www.clifford.at/style.html pour de plus amples explications.

Par ailleurs, rien à voir mais dans le cas des fichiers de configuration, je trouve que redire en commentaire quelque chose qui est dit dans la documentation nuit plus à la lisibilité qu'autre chose (ou alors des trucs du genre "# 0 = off, 1 = on, 2 = auto" quand la syntaxe est mal foutue puisqu'elle n'est pas explicite). C'est d'ailleurs un des trucs qui est dit dans le lien plus haut : « Never explain the programming language or API in your code. ».

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.