Controle de versão

Política trava-modifica-destrava Nessa política, o sistema de controle de versão permite que apenas um desenvolvedor por vez altere um determinado arquivo do projeto. Ela é restritiva e frequentemente atrapalha o trabalho dos usuários. O travamento pode causar alguns problemas administrativos e forçar a uma serialização desnecessária. Alguns dos sistemas que funcionam assim são o ClearCase da Rationa e o Visual Source Safe da Microsoft.

Política copia-modifica-resolve Nessa política, não existe travamento de arquivos. Cada desenvolvedor trabalha livremente em qualquer arquivo da sua cópia de trabalho. Ao fi nal, as alterações de cada desenvolvedor são mescladas no repositório formando a versão fi nal. A solução copia-modi fi ca-resolve parece um pouco estranha e bagunçada a princípio, mas funciona bem na prática. Con fl itos são raros e são causados basicamente pela falta de comunicação e planejamento entre desenvolvedores. Na grande maioria dos casos, as alterações não se sobrepõe e são mescladas automaticamente pelo sistema de controle de versão. O CVS (Concurrent Version System) e Subversion funcionam dessa forma por padrão.

Vocabulário de versionamento: Baseline Uma revisão aprovada de um arquivo (ou de um conjunto de arquivos) onde mudanças subsequentes podem ser feitas. Branch Um conjunto de arquivos podem ser divididos em branches e a partir daquele ponto no tempo duas cópias desses arquivos podem seguir caminhos separados de desenvolvimento separadamente. Change (Mudança) Uma mudança (ou di ff, ou delta) representa uma modi fi cação especí fi ca de um arquivo dentro do controle de versão. Changeset Em sistemas de controle de versão que suportam commits atômicos de múltiplas mudanças, um changeset, change list ou patch identi fi ca o conjunto de mudanças feitas em cada commit.

Vocabulário de versionamento Commit Um commit (ou checkin) ocorre quando uma cópia das modi fi cações feitas na working copy é escrita ou merged no repositório local. Con fl ict (Con fl ito) Um con fl ito ocorre quando duas mudanças feitas no mesmo arquivo e aplicadas concorrentemente e o sistema não consegue reconciliar as mudanças. O usuário deve resolver os con fl itos antes de poder fazer o commit das suas mudanças. Head A revisão mais recente de um repositório. Merge Um merge ou integração é uma operação onde dois changesets são aplicados a um conjunto de arquivos.

Vocabulário de versionamento Repository (Repositório) É onde os dados históricos e eventualmente uma cópia corrente dos arquivos é armazenada. Resolve (Resolver) O ato de consertar con fl itos entre diferentes mudanças num mesmo arquivo. Tag Uma tag ou label referencia um importante snapshot no passado, consistente para vários arquivos. Essa tag pode ter um nome signi fi cativo para simpli fi car referências a esse snapshot. Update Um update sincroniza as mudanças feitas no repositório para a working copy local. Working Copy (Cópia de Trabalho) É uma cópia dos arquivos de um repositório num tempo ou revisão especí fi cos. O trabalho de alteração dos arquivos é sempre feita em uma working copy.

Como Controle de Versão funciona? Base versionada: Cada revisão é um ponto na linha do tempo Commit: processo de marcação no tempo, onde ao ser realizado, ele diz ele diz que o estado atual do que ele esta fazendo deve ser lembrado e, com isso, ele recebe um indentificador de revisão para possivelmente poder recuperar essa versão posteriormente. Push: coloca os arquivos do repositório local no repositório global, bem como as suas mudanças. Pull: busca todas as mudanças ocorridas e os novos arquivos que foram adicionados ao repositório global e os coloca no repositório local.

Operações:

Tags Tags: Marcações de fácil referência, ficando fácil retornar para determinado ponto do código. Ex: Versão 1.0. Versão 1.0: camadas ópticas e elétricas fucnionando e validadas; Versão 1.1: Versão Gerência validada.

Exemplo: Gerenciando o projeto Windows (Poderia ser Linux, mas não quis de propósito)

Sugestão de padrão de uso Branch principal com a versão mais estável possível do código Desenvolvimento de novas funcionalidades feitas em branchs específicos Procedimento de commits e push: 1. Realiza as modificações 2. Sincronize 3. Pull and update 4. Resolver conflitos (caso ocorra) 5. Commit 6. Push