Leçons de niveau 15

Conservation de l'historique dans le génie logiciel/Concepts

Une page de Wikiversité.
Sauter à la navigation Sauter à la recherche
Début de la boite de navigation du chapitre
Concepts
Icône de la faculté
Chapitre no 2
Leçon : Conservation de l'historique dans le génie logiciel
Chap. préc. :Introduction
Chap. suiv. :Outils
fin de la boite de navigation du chapitre
Icon falscher Titel.svg
En raison de limitations techniques, la typographie souhaitable du titre, « Conservation de l'historique dans le génie logiciel : Concepts
Conservation de l'historique dans le génie logiciel/Concepts
 », n'a pu être restituée correctement ci-dessus.

Le changeset est un type primitif[modifier | modifier le wikicode]

Le changeset est un type d'objet aussi essentiel que le fichier, le processus, la liste ou la table associative. Il fait partie des objets numériques dont le néophyte a conscience, par exemple lorsqu’il observe l'évolution d'un article de Wikipédia. Il est dans la boîte à outil du développeur, pour offrir la possibilité à l'utilisateur d'un logiciel de revenir en arrière dans le temps. Il permet de corriger des bugs dans les versions anciennes d'un logiciel sans modifier les versions les plus récentes, en faisant diverger l'histoire des sources.

Dans l'univers numérique, chaque seconde est éternelle[modifier | modifier le wikicode]

Supposons que l'unité de temps du numérique soit le changeset. Pour un ensemble d'octets on pourrait dire qu’il est vieux de 310 changeset. On peut reconstituer l'état du monde tel qu’il était à l'époque de 240 changesets, et donc voyager dans le temps. Lorsqu'on crée un nouveau changeset qui peut s'appliquer à l'époque 240, une réalité alternative (241 bis) apparait, qui peut évoluer de façon indépendante. On peut aussi reprendre tous les changeset qui séparent l'époque 240 et l'époque 310 et tenter de les appliquer sur 241 bis, en restant attentif à éviter des paradoxes temporels.

La divergence n’est pas l'exception, c’est la règle[modifier | modifier le wikicode]

À commencer par la divergence (le fork) qui se crée sur la machine du développeur lorsqu’il corrige un bug. Une fois le changeset qui représente le bug fix, il l'envoie à un ami. Cet ami va réconcilier ce patch avec son histoire et négocier d'éventuels conflits. Lorsque le consensus est trouvé, le nouveau changeset est proposé à d'autres personnes.