Quando o controle de origem foi inventado?

20

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?

P.Brian.Mackey
fonte
18
Na verdade, foi inventado várias vezes, mas eles continuaram perdendo o código fonte.
Reactgular
4
Depende de como você define "controle de origem", mas o IEBUPDTE da IBM remonta a 1962 e foi sem dúvida o VCS mais antigo.
Ross Patterson
2
Se os sistemas de arquivos de versão puderem ser assimilados ao controle de revisão, isso remonta à década de 1960.
Mouviciel
@ RossPatterson, esse comentário realmente precisa ser uma resposta.
31578 John R. Strohm

Respostas:

14

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.

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

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

pdr
fonte
7
O artigo original sobre o SCCS não menciona outros sistemas e parece indicar que ele tinha que apresentar a própria terminologia. Somente dessa fonte, parece que não havia sistema de controle de versões antes de 1972/73.
Martijn Pieters
1
Nomear um sistema de controle de código-fonte "Sistema de controle de código-fonte" é de fato indicação de que foi a primeira instância de algo que se tornaria uma categoria de software posteriormente.
Ingo
@MartijnPieters Rochkind reconhece o CLEAR de Brown no final do artigo e, simplesmente, construindo o SCCS no OS / MVT, ele não poderia ignorar o IEBUPDTE.
Ross Patterson
@ RossPatterson: nem CLEAR nem IEBUPDTE são sistemas de controle de origem. O CLEAR é creditado pela idéia de deltas, afirma explicitamente no artigo que não há outras semelhanças.
Martijn Pieters
3

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.

John R. Strohm
fonte
Os comandos CDC MODIFY e UPDATE eram utilitários para aplicar atualizações de software, não para gerenciar alterações em seu próprio software, tanto quanto eu possa entender. Consulte apps.dtic.mil/dtic/tr/fulltext/u2/a208003.pdf , que descreve os utilitários na página com a página numerada 52 (61 no PDF) e computinghistory.org.uk/downloads/39256 , que descreve o materiais de versão de software no nº 4 (PDF nº 16), como no formato UPDATE.
Martijn Pieters
Acredito que o Xerox SPUDS (sistema de disco de atualização do programa de origem) era um pacote semelhante.
Martijn Pieters
2

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.

Ross Patterson
fonte
O IEBUDTE não é um sistema de atualização de software? É semelhante ao patch, portanto, na melhor das hipóteses, um componente de um sistema de controle de versão. Não há gráfico de mudanças ao longo do tempo, pelo que pude entender.
Martijn Pieters
Sim, IEBUPDTEé semelhante a patch.
Ross Patterson