CVS

An ancient (as in pre-Subversion) presentation on CVS and source code version control, originally for CPM. In Portuguese.

Transcript

1. CVS – Concurrent Versions System Ricardo Bánffy ricardo.banffy@autonomic.com.br
2. Noções Gerais • Um ambiente de produção CVS é composto de duas partes principais: um repositório e pelo menos uma árvore de trabalho
3. Repositório • O repositório é onde ficam os dados das múltiplas versões e da história dos vários arquivos • Ele guarda apenas as diferenças entre as versões (exceto arquivos binários) • Se for fazer back-up de algo, que seja dele • São só arquivos
4. Árvore de Trabalho • É o lugar em que os programadores trabalham • Cada programador tem a sua • Locking otimista – permite mais de uma pessoa trabalhando no mesmo arquivo e resolve os conflitos depois • Precisa receber updates do repositório para que o programador não trabalhe sobre versões velhas (o que não é tão problema assim)
5. Como isso funciona? 1. Alguém cria um repositório 2. Alguém cria um módulo 3. Alguém coloca arquivos dentro do módulo 4. Alguém baixa os arquivos atuais para sua área de trabalho 5. Alguém sobe arquivos mudados para a área de trabalho (cliente CVS sabe quais foram)
6. Por que controlar versões • Saber sempre o que mudou e o que quebrou • Desfazer os erros • Desfazer os erros dos outros • Desfazer os erros da semana passada • Quem fez o que? • Centralizar equipes distribuídas
7. Por que CVS? • Software Livre • Multi-Plataforma • Líder de Mercado • Ampla escolha de ferramentas • Vendor-neutral • Extremamente maduro • Acesso remoto simples
8. O que o CVS não faz • Ele não organiza o seu trabalho • Ele não substitui comunicação entre desenvolvedores • Ele não substitui um gerente de projeto • Ele é só um software • Ele não lida muito bem com coisas que mudam de nome ou de lugar
9. Ampla escolha de front-ends • Command-line: para os bravos, ou para as coisas realmente “cabeludas” – igual em quase qualquer plataforma • WinCVS: Todos os sinos e apitos • MacCvsX: Todos os sinos e apitos, em Mac • gCVS: Para GTK+ • Plug-in para Visual Studio (ainda em pre- release) • Tortoise CVS: Integração total com o Windows Explorer – eu gosto desse • Suporte embutido em seu IDE favorito
10. Mão na massa com o Tortoise CVS • Integrado ao Windows Explorer • Muito, muito fácil de usar (desde que se tenha alguma noção de como o CVS funciona) • Software Livre • Leve (roda em PCs com menos memória que alguns PDAs)
11. Criando um repositório APENAS PARA ADMINISTRADORES!!! • Crie uma pasta em um servidor. Dentro dela crie outra pasta chamada CVSROOT
12. Criando um módulo • Selecione a pasta de trabalho e, no menu de contexto, escolha “CVS>Make New Module” • Na pasta que contém os arquivos escolha “CVS Add Contents” • Entre na pasta e observe os ícones vermelhos • Escolha “CVS Commit” – Se quiser contar um pouco da história dessa atualização, agora é um bom momento
13. Criando um módulo • Diga que o repositório está em (no nosso caso) p:\repositorio • Lembre-se que acentos e espaços em nomes de arquivos dão azar
14. Uma caixa de areia só sua • O primeiro passo para começar a trabalhar com um projeto no CVS é gerar sua cópia de trabalho • Em uma pasta vazia, escolha “CVS Checkout” • No CVSROOT coloque “:local:p:\\repositorio” e escolha o módulo “projeto” • Na pasta, escola “CVS Update” • Verde indica que o arquivo não foi modificado desde que foi trazido do repositório • As últimas alterações são baixadas para sua máquina com “CVS Update” – faça isso com frequência
15. Você mudou coisas • Quando você muda coisas, é hora de usar o “Commit” de novo • Commit manda tudo o que está “pendente” na sua área de trabalho para o servidor • Se houver conflitos, ele consegue resolver automaticamente sozinho (ele avisa, claro) • Se ele não conseguir, ele espera que você arrume
16. Dia do release • Você pode marcar um determinado conjunto de arquivos como uma versão. Para isso, use “CVS>Tag” • Usando “Update Special” você pode obter os arquivos de um determinado tag ou de uma determinada data. • CVS não faz nem build nem deploy (até certo ponto). Isso é por sua conta.
17. Dois cenários • Scripts – Basta copiar os arquivos de uma determinada versão para o servidor de web – Você pode, inclusive, servir as páginas a partir de uma área de trabalho do CVS e atualizá-las com “update” • Programas Compilados – Você pode guardar os makefiles junto dos fontes no CVS – Você faz o build e o deployment
18. Tags e Branches • Você liberou a versão 1.0 do produto • Mas ela tinha um bug sério • Só que os fontes estão entre a 1.0 e a 1.1 • E você precisa consertar a 1.0 • Você faz um branch sobre o tag que você criou • Você trabalha no branch • Quando arrumar, faz o merge (ou não)
19. Gráfico de Revisões • Estamos trabalhando na revisão 1.1.2.1 do arquivo “teste.py” (que faz parte da versão 1.0.1, do branch “testes”, sendo que a revisão 1.1 é parte da versão 1.0 e a 1.2 é a mais atual
20. Palavras Mágicas • $Id$ - Nome do arquivo, revisão, autor, data • $Revision$ - Identificador da revisão • $Author$ - Login do usuário que fez o último check-in • $Log$ - Comentário do check-in • $Date$ - Quando essa versão foi acrescentada ao repositório
21. Só programas? • Você pode guardar mais coisas no CVS além dos fontes • Documentação (cuidado com arquivos binários) • Imagens, scripts de ajuda, carga inicial de BD, dados de testes, etc. • Makefiles, arquivos de projeto (mas eu já disse isso)
22. Fazendo back-up • O repositório não sabe nada sobre os clientes – só sabe do código e das revisões • Copiar os arquivos basta
23. Voltando o back-up • Em caso de desastre, trazer os arquivos de volta resolve • Desenvolvedores fazem novo update e resolvem eventuais conflitos
24. Dúvidas?
25. Para saber mais “O” CVS: http://www.cvshome.org Tortoise CVS: http://www.tortoisecvs.org WinCVS, MacCvsX, gCVS: http://www.wincvs.org Version Management with CVS: http://www.cvshome.org/docs/manual/