Quando o controle de origem foi inventado?

Estou ciente de muitos sistemas de controle de versão: CVS, SVN, TFS etc ...

Pesquisei no Google o primeiro "sistema de controle de revisão / controle de versão" e vi várias respostas conflitantes.

Quando o controle de origem foi inventado? Quem inventou isso? Como se chamava?

Aqui está uma linha do tempo bastante decente dos principais players em formato de vídeo (sem som).

Isso sugere que o SCCS foi o primeiro, por uma margem de cerca de 9 anos.

Há muita coisa faltando por lá, como evidenciado por este blog e pelos comentários resultantes.

Em 1981, trabalhei em um emprego de verão na Charter Information em Austin, TX. Eles eram anteriormente Commercial Information Corporation de Woburn MA. Eles executaram um Xerox Sigma 6 que foi atualizado em campo para um Sigma 7. Eles usaram uma coisa chamada SPUD (Source Program Update) para controle de código-fonte. Foi baseado em fita.

Eu montei rotineiramente a "fita SPUD bicentenária" e trabalhei em um deck mod para um pedaço de código nessa fita. Foi chamada de "fita SPUD bicentenária" porque foi escrita em 1976. Eles tinham fitas mais antigas, indicando que o SPUD voltou mais longe do que 1976.

Enquanto estudante na UT Austin (1973-1981), me deparei com o MODIFY e UPDATE, dois programas de controle de código-fonte da Control Data Corporation para o CDC 6600 e mainframes posteriores. Não sei quando eles foram lançados pela primeira vez, mas suspeito que saíram pouco depois do 6600, que (se a memória me serve) saiu no final dos anos 1960.

Suspeito que a IBM tenha algo bem antes de qualquer outra pessoa, mas não tenho nenhum conhecimento da história do mainframe da IBM e gosto dessa maneira.

O programa IEBUPDTE , originalmente criado para o sistema OS / 360 da IBM, remonta a 1962, 10 anos mais antigo que o SCCS . Seu objetivo é aplicar um conjunto de alterações a um conjunto de programas de origem de entrada, criando um conjunto de programas de origem modificados. Todo o código-fonte foi gerenciado como "decks" de cartões perfurados de 80 colunas ou como arquivos semelhantes a eles. Esses decks do programa de origem tinham "números de sequência" em um conjunto fixo de colunas em cada linha ou cartão ( COBOL especificavam à esquerda, nas colunas 1-6, quase tudo o mais supunha que eles estavam à direita nas colunas 73-80 ) Os números de sequência tiveram que aumentar linha por linha, mas a maioria do código-fonte aumentou em 10s, 100s ou 1000s, para permitir espaço no espaço numérico integral entre duas linhas para inserções posteriores.

Um deck de controle IEBUPDTE típico pode se parecer com:

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

que modificaria dois arquivos de origem, "PROG001" e "PROG002", substituindo o número da linha "5000" (geralmente a 5ª linha, seguindo a prática "número por milhares") e excluindo as linhas 9000 a 15000 no PROG001 e substituindo a linha 92000 no PROG002 .

No nível mais simples, essa é uma definição de Controle de Origem. O pessoal do Unix reconheceria isso como o patch faz, mas usando numeração explícita em vez de implícita. Era comum aplicar conjuntos de decks de controle a um programa de entrada em sequência e armazenar esses conjuntos como um arquivo de disco coeso (um Conjunto de dados particionado ), que possui uma forte semelhança com os históricos de alterações que o CVS e o RCS armazenam em seus ,varquivos. A IBM costumava fornecer patches de código chamados PTFs ( Program Temporary Fixes ) na forma de grandes decks de controle que modificavam os arquivos como parte de um único conjunto de alterações relacionado, que os usuários do Subversion e Git achavam familiar.