Quand le contrôle des sources a-t-il été inventé?

Je connais de nombreux systèmes de contrôle de version: CVS, SVN, TFS etc ...

J'ai googlé pour le tout premier "système de contrôle de révision / contrôle de version" et j'ai vu diverses réponses contradictoires.

Quand le contrôle des sources a-t-il été inventé? Qui l'a inventé? Comment s'appelait-il?

Voici une chronologie assez décente des principaux acteurs sous forme vidéo (pas de son).

Il suggère que le SCCS a été le premier, avec une marge d'environ 9 ans.

Il manque cependant beaucoup, comme en témoigne ce blog et les commentaires qui en découlent.

En 1981, j'ai travaillé un emploi d'été chez Charter Information à Austin au Texas. Ils étaient auparavant Commercial Information Corporation de Woburn MA. Ils ont exécuté un Xerox Sigma 6 qui avait été mis à niveau sur le terrain vers un Sigma 7. Ils ont utilisé une chose appelée SPUD (Source Program Update) pour le contrôle du code source. C'était sur bande.

J'ai régulièrement monté la "bande SPUD bicentenaire" et travaillé sur une plate-forme mod pour un morceau de code sur cette bande. On l'appelait la "bande SPUD bicentenaire" car elle avait été écrite en 1976. Ils avaient des bandes plus anciennes, ce qui indique que la SPUD remontait plus loin que 1976.

Pendant mes études à UT Austin (1973-1981), je me suis heurté à MODIFY et UPDATE, deux programmes de contrôle de code source de Control Data Corporation pour le CDC 6600 et les mainframes ultérieurs. Je ne sais pas quand ils sont sortis pour la première fois, mais je soupçonne qu'ils sont sortis peu de temps après le 6600, qui (si ma mémoire est bonne) est sorti à la fin des années 1960.

Je soupçonne qu'IBM avait quelque chose de bien avant tout le monde, mais je n'ai aucune connaissance de l'histoire des grands systèmes IBM, et j'aime ça.

Le programme IEBUPDTE , créé à l'origine pour le système OS / 360 d'IBM, remonte à 1962, 10 ans de plus que SCCS . Son but est d'appliquer un ensemble de modifications à un ensemble de programmes source d'entrée, en créant un ensemble de programmes source modifiés. Tout le code source était géré soit comme des «jeux» de cartes perforées à 80 colonnes , soit comme des fichiers qui leur ressemblaient. Ces platines de programme source avaient des «numéros de séquence» dans un ensemble fixe de colonnes sur chaque ligne ou carte ( COBOLles a spécifiés comme étant à gauche, dans les colonnes 1 à 6, presque tout le reste les a supposés être à droite dans les colonnes 73 à 80). Les numéros de séquence ont dû augmenter ligne par ligne, mais la plupart du code source a augmenté de 10s, 100s ou 1000s, pour laisser de la place dans l'espace numérique intégral entre deux lignes pour les insertions ultérieures.

Un pont de contrôle IEBUPDTE typique pourrait ressembler à:

./ CHANGE NAME=PROG001
         PROGRAM XYZZY                                                  00005000
./ DELETE SEQ1=9000,SEQ2=15000
         DO I=1,10                                                      00026000
./ CHANGE NAME=PROG002
         J=256                                                          00092000
./ ENDUP

qui modifierait deux fichiers sources, "PROG001" et "PROG002", remplaçant le numéro de ligne "5000" (souvent la 5ème ligne, suivant la pratique "nombre par milliers") et supprimant les lignes 9000 à 15000 dans PROG001 et remplaçant la ligne 92000 dans PROG002 .

À son niveau le plus simple, c'est une définition du contrôle de source. Les gens d'Unix reconnaîtraient cela comme le fait le patch , mais en utilisant une numérotation explicite au lieu d'implicite. Il était courant d'appliquer des ensembles de decks de contrôle à un programme d'entrée en séquence et de stocker ces ensembles sous forme de fichier de disque cohérent (un ensemble de données partitionné ), ce qui présente une forte similitude avec les historiques de modifications que CVS et RCS stockent dans leurs ,vfichiers. IBM fournissait fréquemment des correctifs de code appelés Program Temporary Fixes (PTF) sous la forme de grands decks de contrôle qui modifiaient les fichiers dans le cadre d'un ensemble de modifications associé, que les utilisateurs de Subversion et Git trouveraient familiers.