Quando è stato inventato il controllo del codice sorgente?

Sono a conoscenza di molti sistemi di controllo versione: CVS, SVN, TFS ecc ...

Ho cercato su Google il primo "sistema di controllo di revisione / controllo versione" e ho visto varie risposte contrastanti.

Quando è stato inventato il controllo del codice sorgente? Chi lo ha inventato? Come si chiamava?

Ecco una linea temporale abbastanza decente dei principali giocatori in forma video (senza audio).

Suggerisce che SCCS fu il primo, con un margine di circa 9 anni.

Tuttavia, ci sono molte cose da perdere, come evidenziato da questo blog e dai commenti che ne risultano.

Nel 1981, ho svolto un lavoro estivo presso Charter Information ad Austin, in Texas. In precedenza erano Commercial Information Corporation di Woburn MA. Hanno eseguito un Xerox Sigma 6 che era stato aggiornato sul campo a un Sigma 7. Hanno usato una cosa chiamata SPUD (Source Program Update) per il controllo del codice sorgente. Era basato su nastro.

Ho regolarmente montato il "nastro SPUD bicentenario" e ho lavorato su un deck mod per un pezzo di codice su quel nastro. È stato chiamato "nastro SPUD bicentenario" perché è stato scritto nel 1976. Avevano nastri più vecchi, indicando che SPUD è tornato più lontano del 1976.

Mentre studiavo alla UT Austin (1973-1981), mi sono imbattuto in MODIFY e UPDATE, due programmi di controllo del codice sorgente di Control Data Corporation per il CDC 6600 e successivi mainframe. Non so quando uscirono per la prima volta, ma sospetto che siano usciti non molto dopo il 6600, che (se la memoria mi serve) è uscito alla fine degli anni '60.

Sospetto che IBM avesse qualcosa di ben prima di chiunque altro, ma non ho alcuna conoscenza della storia del mainframe IBM e mi piace così.

Il programma IEBUPDTE , originariamente creato per il sistema OS / 360 di IBM, risale al 1962, 10 anni più vecchio di SCCS . Il suo scopo è applicare una serie di modifiche a una serie di programmi di input source, creando una serie di programmi di source modificati. Tutto il codice sorgente è stato gestito come "deck" di schede perforate a 80 colonne o come file che le somigliavano. Questi deck del programma sorgente avevano "numeri di sequenza" in una serie fissa di colonne su ogni riga o scheda ( COBOLli ha specificati per essere a sinistra, nelle colonne 1-6, quasi tutto il resto ha assunto che fossero a destra nelle colonne 73-80). I numeri di sequenza dovevano aumentare riga per riga, ma la maggior parte del codice sorgente aumentava di 10, 100 o 1000, per consentire spazio nello spazio numerico integrale tra due righe per inserimenti successivi.

Un tipico control deck IEBUPDTE potrebbe apparire come:

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

che modifica due file di origine, "PROG001" e "PROG002", sostituendo il numero di riga "5000" (spesso la 5a riga, seguendo la pratica "numero per migliaia") ed eliminando le righe da 9000 a 15000 in PROG001 e sostituendo la riga 92000 in PROG002 .

Al suo livello più semplice, questa è una definizione di controllo del codice sorgente. La gente di Unix lo riconoscerebbe come fa la patch , ma usando la numerazione esplicita anziché implicita. Era comune applicare sequenze di deck di controllo a un programma di input in sequenza e archiviarle come file di disco coesivo (un set di dati partizionato ), che presenta una forte somiglianza con le cronologie dei cambiamenti che CVS e RCS memorizzano nei loro ,vfile. IBM distribuiva frequentemente patch di codice chiamate PTF ( Program Temporary Fixes ) sotto forma di grandi deck di controllo che modificavano i file come parte di un singolo changeset correlato, che gli utenti di Subversion e Git avrebbero trovato familiari.