História: Como era feito o controle de versão inicialmente e como foi progredindo





Pré-história 

Houve um momento em que você armazenou suas versões manualmente. Ok, para muitos de vocês desta vez não eram os anos 80, mas alguns anos atrás, quando você estava na faculdade, nomeando seus arquivos de código fonte de exercícios.zip, exercise-0.zip, exercise-good.zip, exercise-good- final.zip, e assim por diante. Bem, acredite ou não, houve um tempo sem SCMs reais. Era sempre escuro e as pessoas viviam em cavernas.

RCS 

Em 1982 o RCS foi lançado, ele é uma tecnologia enorme, mas você ainda pode encontrá-lo em distros do Unix. É simples e direto ao ponto. Um bom recurso foi que as mudanças de texto foram armazenadas como deltas (muito importante, considerando que os discos rígidos costumavam ser pequenos!). Deltas ainda são usados ​​atualmente pela maioria dos SCMs. Algumas desvantagens do RCS merecem destaque: É apenas texto. Não existe um repositório central; Cada arquivo controlado por versão possui seu próprio repo, sob a forma de um arquivo RCS, armazenado perto do próprio arquivo. Por exemplo, o arquivo RCS para /usr/project/foo.c é /usr/project/foo.c,v - ou um pouco melhor, em um subdiretório, /usr/project/RCS/foo.c,v. Os desenvolvedores criam espaços de trabalho privados criando links simbólicos para subdiretórios RCS - digamos, um link simbólico de / usr / home / john / RCS para / usr / project / RCS. Nomeação de versões e ramos é francamente hostil. Uma versão pode ser chamada 1.3, e um ramo pode ser chamado 1.3.1 e uma versão no ramo pode ser chamada 1.3.1.7.

A era clássica
Na arena SCM, os anos 90 são a era clássica. 

CVS

Tudo começou com CVS (Concurrent Version System) em 1990. Foi capaz de lidar com várias versões que estão sendo desenvolvidas simultaneamente em diferentes máquinas e armazenadas em um servidor central. A era cliente-servidor estava sobre nós e os desenvolvedores aproveitaram a maior vantagem. O CVS conseguiu lidar com versões de forma decente. E até apoiou ramificação e fusão, embora não fosse muito bom fazê-lo. Essa é uma das razões pelas quais muitas pessoas tem medo da palavra "B" e da palavra "M". O CVS não rastreou diretórios ou alterações no nome do arquivo (nenhuma refatoração permitida aqui!) E dependia fortemente do bloqueio de todo o repositório. Está desatualizado agora, mas funcionou nos anos 90! (Se você tiver, simplesmente vá embora e vá para outra coisa!) 

Entre na Idade Média 

Um tempo de escuridão, quando a maioria dos avanços anteriores foram perdidos e um ambiente degradado surgiu ... 

Subversion 

O Subversion (SVN) foi concebido como "CVS aprimorado" e seus desenvolvedores atingiram seu alvo: é melhor do que o CVS. Período. Embora sistemas como o ClearCase fossem perfeitamente capazes de ramificação e fusão, o SVN criou uma geração completa de desenvolvedores no seguinte dogma: medo de ramificação e fusão a todo custo! Isso causou danos ambientais que persistem até hoje, apenas começando a ser curados pela nova geração de DVCS. SVN estava perto de P4 em recursos, e se espalhou como louco: mais de 5 milhões de desenvolvedores em todo o mundo usam SVN diariamente. Enorme!

Entre no Renascimento 

Após uma era de escuridão, uma geração inteiramente nova de sistemas SCM quebrou o status quo estabelecido. "SCM é um mercado maduro" foi a sabedoria convencional dos analistas, mas a nova geração entrou na cena e explodiu tudo à parte. Capaz de separar os laços com a Internet e trabalhar desconectado (como as estrelas do rock legal), a nova geração também se destaca na ramificação e fusão, que foi promovido como a raiz de todo o mal durante as "idades das trevas". Estes novos sistemas mudaram com sucesso a maré na direção "ramificação / fusão é boa". 

Git 
Linus Torvalds, o próprio pai do próprio Linux, projetou e implementou a primeira versão do Git (quase em um fim de semana, em estilo puro hacker) para dar aos seus desenvolvedores do kernel uma alternativa ao BitKeeper. Linus não só fez o design original (simples, limpo, genial), mas ajudou a promover o projeto com seu estilo único. (Consulte http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html.) Durante seu famoso discurso, ele criticou fortemente (ok, insultado) CVS, SVN e Perforce: "Subversion foi o projeto mais inútil já iniciado", "Se você gosta de usar CVS, você deve estar em algum tipo de instituição mental ou em algum lugar mais "e, finalmente," Livrar-se de Perforce, é triste, mas é tão, tão verdadeiro ". Você pode amá-lo ou odiá-lo, mas ele definitivamente fez sua opinião: a Idade Média acabou e agora os sistemas distribuídos governavam o mundo, incluindo a remoção do medo arcano de ramificação e fusão, um conceito chave por trás de cada DVCS. Durante os próximos anos, todos os principais projetos de código aberto migraram para longe de Subversion para Git (e www.github.com forneceu um enorme e enorme serviço de hospedagem), tornando-o o mais forte e legal do SCM na Terra. O Git baseia-se em uma estrutura DAG (Diagrama acíclico direcionado), na qual a unidade principal de mudança é o conjunto de mudanças. Ele implementa o rastreamento de mesclagem total, mas no nível de confirmação em vez do nível de revisão de arquivo individual (como, por exemplo, o ClearCase faz). É extremamente rápido, com as únicas advertências sendo o gerenciamento de grandes arquivos binários e a necessidade de replicar repositórios na sua totalidade. Git é claramente influenciado por suas raízes de kernel, e obviamente não é a coisa mais fácil na Terra de usar. Mas definitivamente será o SCM da próxima década


Autor: Guilherme Boroni
 

 

Comentários

Postagens mais visitadas deste blog

Plano de Projeto de Software do SIUR

Vocabulário comum entre os Sistemas de Controle de Versão

Git