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


20

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?



18
Il a en fait été inventé plusieurs fois, mais ils ont continué à perdre le code source.
Reactgular

4
Cela dépend de la façon dont vous définissez le "contrôle de code source", mais IEBUPDTE d'IBM remonte à 1962, et c'était sans doute le premier VCS.
Ross Patterson

2
Si les systèmes de fichiers de version peuvent être assimilés au contrôle de révision, cela remonte aux années 1960.
mouviciel

@ RossPatterson, ce commentaire doit vraiment être une réponse.
John R. Strohm

Réponses:


14

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.

http://i.stack.imgur.com/wcAWD.png

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


7
Le document original sur le SCCS ne mentionne aucun autre système et semble indiquer qu'il a dû trouver la terminologie elle-même. De cette seule source, il semble qu'il n'y ait pas de système de contrôle de version avant 1972/73.
Martijn Pieters le

1
Nommer un système de contrôle de code source "Système de contrôle de code source" est en effet une indication qu'il s'agissait de la première instance de quelque chose qui allait devenir une catégorie de logiciel plus tard.
Ingo

@MartijnPieters Rochkind reconnaît CLEAR de Brown à la fin du document, et simplement, en construisant SCCS sur OS / MVT, il ne pouvait pas ignorer IEBUPDTE.
Ross Patterson

@ RossPatterson: ni CLEAR ni IEBUPDTE ne sont des systèmes de contrôle de source. CLEAR est crédité de l'idée de deltas, il indique explicitement dans le document qu'il n'y a pas d'autres similitudes.
Martijn Pieters

3

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.


Les commandes CDC MODIFY et UPDATE étaient des utilitaires pour appliquer les mises à jour logicielles, pas pour gérer les changements dans votre propre logiciel, pour autant que je puisse en juger. Voir apps.dtic.mil/dtic/tr/fulltext/u2/a208003.pdf , qui décrit les utilitaires à la page la page numérotée 52 (61 dans le PDF), et computinghistory.org.uk/downloads/39256 , qui décrit le les documents de sortie du logiciel sur # 4 (PDF # 16) sont à venir au format UPDATE.
Martijn Pieters

Je crois que Xerox SPUDS (Source Program Update Disk System) était un package similaire.
Martijn Pieters

2

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.


IEBUDTE n'est-il pas un système de mise à jour logicielle? C'est similaire au patch, donc au mieux un composant d'un système de contrôle de version. Il n'y a pas de graphique des changements dans le temps, autant que je sache.
Martijn Pieters

Ouaip, IEBUPDTEest similaire à patch.
Ross Patterson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.