1.1 Primeiros Passos - Sobre Controle de Versão

O método de controle de versão preferido de muitas pessoas é copiar os arquivos para outro diretório (talvez um diretório com carimbo de data/hora, se elas forem espertas). Essa abordagem é muito comum porque é muito simples, mas também é incrivelmente sujeita a erros. É fácil esquecer em qual diretório você está e acidentalmente escrever no arquivo errado ou sobrescrever arquivos que você não pretendia.

Para lidar com esse problema, os programadores desenvolveram, há muito tempo, VCSs locais que tinham um banco de dados simples que mantinha todas as alterações nos arquivos sob controle de revisão.

Uma das ferramentas VCS mais populares foi um sistema chamado RCS, que ainda é distribuído com muitos computadores hoje. O RCS funciona mantendo conjuntos de patches (isto é, as diferenças entre arquivos) em um formato especial no disco; ele pode então recriar a aparência de qualquer arquivo em qualquer ponto no tempo, somando todos os patches.

O próximo grande problema que as pessoas encontram é que precisam colaborar com desenvolvedores em outros sistemas. Para lidar com esse problema, os Sistemas de Controle de Versão Centralizados (CVCSs) foram desenvolvidos. Esses sistemas (como CVS, Subversion e Perforce) possuem um único servidor que contém todos os arquivos versionados, e vários clientes que fazem o checkout dos arquivos desse local central. Por muitos anos, este tem sido o padrão para controle de versão.

Essa configuração oferece muitas vantagens, especialmente sobre os VCSs locais. Por exemplo, todo mundo sabe, até certo ponto, o que todos os outros no projeto estão fazendo. Os administradores têm um controle refinado sobre quem pode fazer o quê, e é muito mais fácil administrar um CVCS do que lidar com bancos de dados locais em cada cliente.

No entanto, essa configuração também tem algumas desvantagens sérias. A mais óbvia é o ponto único de falha que o servidor centralizado representa. Se esse servidor ficar inativo por uma hora, durante essa hora ninguém poderá colaborar de forma alguma ou salvar alterações versionadas em nada no qual estejam trabalhando. Se o disco rígido onde o banco de dados central está for corrompido e não tiverem sido mantidos backups adequados, você perde absolutamente tudo — o histórico inteiro do projeto, exceto quaisquer snapshots únicos que as pessoas tenham em suas máquinas locais. Os VCSs locais sofrem do mesmo problema — sempre que você tem o histórico inteiro do projeto em um único lugar, corre o risco de perder tudo.

É aqui que os Sistemas de Controle de Versão Distribuídos (DVCSs) entram em cena. Em um DVCS (como Git, Mercurial ou Darcs), os clientes não fazem apenas o checkout do snapshot mais recente dos arquivos; em vez disso, eles espelham totalmente o repositório, incluindo todo o seu histórico. Assim, se qualquer servidor morrer, e esses sistemas estivessem colaborando através desse servidor, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo. Cada clone é realmente um backup completo de todos os dados.

Além disso, muitos desses sistemas lidam muito bem com a existência de vários repositórios remotos com os quais podem trabalhar, de modo que você pode colaborar com diferentes grupos de pessoas de diferentes maneiras, simultaneamente, dentro do mesmo projeto. Isso permite que você configure vários tipos de fluxos de trabalho que não são possíveis em sistemas centralizados, como modelos hierárquicos.