Um pouco sobre Subversion

O que é Subversion?

Subversion é um sistema de controle de versão livre/open-source. Isto é, o Subversion gerencia arquivos e diretórios, e as modificações feitas neles ao longo do tempo. Isto permite que você recupere versões antigas de seus dados, ou que examine o histórico de suas alterações.

História do Subversion

No começo do ano 2000, a CollabNet, Inc. (http://www.collab.net) começou a procurar profissionais para desenvolver um substituto para o CVS. O CVS havia se firmado como um padrão de fato no mundo open source principalmente porque não havia nada melhor, pelo menos sob licença livre. Então a CollabNet decidiu desenvolver um novo sistema de controle de versão a partir do zero, mantendo as idéias básicas do CVS, mas sem os bugs e seus inconvenientes.

A CollabNet contratou Karl e Ben Collins-Sussman, e um projeto detalhado de trabalho começou em Maio. Com a ajuda e incentivo de Brian Behlendorf, Jason Robbins e Greg Stein. A equipe não queria romper com a metodologia existente para controle de versão, eles apenas queriam corrigir o CVS. Eles decidiram que o Subversion deveria ser compatível com as características do CVS, e manter o mesmo modelo de desenvolvimento, mas não reproduzir as falhas mais óbvias do CVS. E mesmo que o novo sistema não fosse um substituto definitivo para o CVS, ele deveria ser suficientemente semelhante a este para que qualquer usuário do CVS pudesse migrar de sistema com pouco esforço.

Depois de quatorze meses de desenvolvimento, o Subversion tornou-se “auto-gerenciável” em 31 de Agosto de 2001. Ou seja, os desenvolvedores do Subversion pararam de usar o CVS para gerir seu próprio código-fonte, e começaram a usar o próprio Subversion no lugar.

Características do Subversion

O Subversion proporciona:

Versionamento de diretórios

O CVS apenas rastreia o histórico de arquivos individuais, já o Subversion implementa um sistema de arquivos “virtual” sob controle de versão que rastreia modificações a toda a árvore de diretório ao longo do tempo. Os arquivos e os diretórios são versionados.

Histórico de versões efetivo

Como o CVS é limitado apenas ao versionamento de arquivos, operações como cópia e renomeação (que podem ocorrer com arquivos também, mas que são realmente alterações no conteúdo de algum diretório continente) não são suportadas no CVS. Adicionalmente, no CVS você não pode substituir um arquivo versionado por alguma outra coisa com o mesmo nome sem que o novo item deixe de herdar o histórico do arquivo antigo (que talvez seja até algo com o qual não mantenha nenhuma correlação). Com o Subversion, você pode adicionar, excluir, copiar, e renomear ambos os arquivos ou diretórios e cada novo arquivo adicionado começa com um histórico próprio e completamente novo.

Commits atômicos

Um conjunto de modificações ou é inteiramente registrado no repositório, ou não é registrado de forma nenhuma. Isto possibilita aos desenvolvedores criarem e registrarem alterações como blocos lógicos, e também evita problemas que possam ocorrer quando apenas uma parte de um conjunto de alterações seja enviada com sucesso ao repositório.

Versionamento de metadados

Cada arquivo e diretório tem um conjunto de propriedades(chaves e seus valores) associados consigo. Você pode criar e armazenar quaisquer pares chave/valor que quiser. As propriedades são versionadas ao longo do tempo, tal como os conteúdos de arquivo.

Escolha das camadas de rede

O Subversion tem uma noção abstrata do acesso ao repositório, tornando-o mais fácil para as pessoas implementarem novos mecanismos de rede. O Subversion pode se associar ao servidor Apache HTTP como um módulo de extensão. Isto dá ao Subversion uma grande vantagem em estabilidade e interoperabilidade, além de acesso instantâneo aos recursos existentes oferecidos por este servidor-autenticação, autorização, compactação online, dentre outros. Um servidor Subversion mais leve e independente também está disponível. Este servidor utiliza um protocolo específico o qual pode ser facilmente ser tunelado sobre SSH.

Manipulação consistente de dados

O Subversion exprime as diferenças de arquivo usando um algoritmo diferenciado, o qual funciona de maneira idêntica tanto em arquivos texto (compreensível para humanos) quanto em arquivos binários (incompreensível para humanos). Ambos os tipos de arquivos são igualmente armazenados de forma compactada no repositório, e as diferenças são enviadas em ambas as direções pela rede.

Ramificações e rotulagem eficiente

O custo de se fazer ramificações (branching) e de rotulagem (tagging) não precisa ser proporcional ao tamanho do projeto. O Subversion cria ramos e rótulos simplesmente copiando o projeto, usando um mecanismo semelhante a um hard-link. Assim essas operações levam apenas uma pequena e constante quantidade de tempo.

Hackability

O Subversion não tem qualquer bagagem histórica; ele é implementado como um conjunto de bibliotecas C compartilhadas com APIs bem definidas. Isto torna o Subversion extremamente manutenível e usável por outras aplicações e linguagens.

O Repositório

O Subversion é um sistema centralizado de compartilhamento de informação. Em seu núcleo está um repositório, que é uma central de armazenamento de dados. O repositório armazena informação em forma de uma árvore de arquivos – uma hierarquia típica de arquivos e diretórios. Qualquer número de clientes se conecta ao repositório, e então lê ou escreve nestes arquivos. Ao gravar dados, um cliente torna a informação disponível para outros; ao ler os dados, o cliente recebe informação de outros.

Figura abaixo: “Um típico sistema cliente/servidor” ilustra isso.

O Problema do Compartilhamento de Arquivos

Todos os sistemas de controle de versão têm de resolver o mesmo problema fundamental: como o sistema permitirá que os usuários compartilhem informação, e como ele prevenirá conflitos, pois é muito fácil para os usuários acidentalmente sobrescrever as mudanças feitas pelos outros no repositório.

A Solução Lock-Modify-Unlock

Muitos sistemas de controle de versão usam o modelo lock-modify-unlock (travar-modificar-destravar) para resolver o problema de vários autores destruírem o trabalho uns dos outros. Neste modelo, o repositório permite que apenas uma pessoa de cada vez altere o arquivo, essa política de exclusividade é gerenciada usando locks (travas).

A figura abaixo: “modelo lock-modify-unlock”.

Apesar de usual esse modelo tem problemas como:

Locks podem causar problemas administrativos: se um usuário “travar” o arquivo resulta em perda de tempo para os outros usuários.

Locking pode causar serialização desnecessária: um mesmo arquivo modificado em partes distintas por dois usuários diferentes não pode ser feito.

Locking pode criar falsa sensação de segurança: se um arquivo A for modificado por um usuário e um arquivo B for modificado por um outro usuário, mas A e B possuíam dependências mutuas gerara erro se algo foi modificado.

Solução Copy-Modify-Merge

O Subversion usa o modelo de copy-modify-merge (copiar-modificar-fundir) como uma alternativa ao locking. Nesse modelo, cada usuário se conecta ao repositório do projeto e cria uma cópia de trabalho pessoal (personal working copy, ou cópia local) - um espelho local dos arquivos e diretórios do repositório. Os usuários então trabalham simultaneamente e independentemente, modificando suas cópias privadas. Finalmente, as cópias privadas são fundidas (merged) numa nova versão final. O sistema de controle de versão frequentemente ajuda com a fusão, mas, no final, a intervenção humana é a única capaz de garantir que as mudanças foram realizadas de forma correta.

Figura abaixo exemplo demonstrativo de seu funcionamento:

Quando um usuário sobrescreve alterações feitas por outro ocorre uma situação de conflito e no momento da fusão entre as alterações efetuadas pelos usuários haverá uma sinalização, os usuários envolvidos decidirão qual versão será consolidada. O modelo copy-modify-merge pode soar um pouco caótico, mas, na prática, ele funciona de forma bastante suave. Os usuários podem trabalhar em paralelo, nunca esperando uns pelos outros. Quando eles trabalham nos mesmos arquivos, verifica-se que a maioria de suas alterações simultâneas não se sobrepõe afinal; conflitos não são muito frequentes. E a quantidade de tempo que eles levam para resolver os conflitos é geralmente muito menor que o tempo perdido no sistema de locking.

Pode-se imaginar que o modelo o modelo copy substituiria o lock, mas o modelo lock é necessário em situações onde a modificação pode acarretar erro ou a perca da informação como arquivos binários ou elementos visuais como fotos ou vídeos, a substituição parcial pode acarretar na perda parcial ou total do arquivo.