Quando è stato inventato il controllo del codice sorgente?

Ecco una timeline abbastanza decente dei principali attori in formato video (nessun suono).

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

Mancano però molte cose, come evidenziato da questo blog e i commenti risultanti.

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

Ho montato di routine il "nastro SPUD bicentenario" e ho lavorato su un deck mod per un pezzo di codice su quel nastro. Si chiamava "nastro bicolore SPUD" perché era stato scritto nel 1976. Avevano nastri più vecchi, a indicare che SPUD risaliva più indietro del 1976.

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

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

Il programma IEBUPDTE , creato originariamente 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 un insieme di programmi sorgente di input, creando una serie di programmi sorgente modificati. Tutto il codice sorgente è stato gestito come "mazzo" di schede perforate a 80 colonne, o come file simili loro. Questi mazzi di programmi sorgente avevano "numeri di sequenza" in un set fisso di colonne su ogni riga o carta ( COBOL li ha specificati a sinistra, nelle colonne 1-6, quasi tutto il resto suppone che siano a destra nelle colonne 73-80). I numeri di sequenza dovevano aumentare riga per riga, ma la maggior parte del codice sorgente aumentava di 10s, 100s o 1000s, per consentire spazio nello spazio dei numeri interi tra due linee per gli inserimenti successivi.

Un tipico mazzo di controllo IEBUPDTE potrebbe essere simile a:

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

che modificerebbe due file sorgente, "PROG001" e "PROG002", sostituendo il numero di linea "5000" (spesso la quinta riga, seguendo la pratica "numero per migliaia") ed eliminando le linee da 9000 a 15000 in PROG001 e sostituendo la linea 92000 in PROG002.

Al suo livello più semplice, questa è una definizione di controllo del codice sorgente. La gente di Unix lo riconoscerebbe come ciò che fa la patch , ma usando la numerazione esplicita invece che implicita. Era comune applicare set di control control a un programma di input in sequenza e archiviarli come un file disco coesivo (a Dataset partizionato ), che presenta una strong somiglianza con le cronologie dei cambiamenti che CVS e RCS memorizza nei loro file ,v . IBM distribuiva frequentemente patch di codice denominate Correzioni temporanee del programma (PTF) sotto forma di mazzi di controllo di grandi dimensioni che modificavano i file come parte di un singolo changeset correlato, che Subversion e Git gli utenti troveranno familiare.