O documento discute gestão de configuração de software usando o CVS. Aborda tópicos como etiquetas, ramos, mesclagem de ramos, exportação de projetos e boas práticas. Explica como usar etiquetas para marcar liberações importantes, como criar e trabalhar em ramos para desenvolvimento paralelo, e como mesclar alterações entre ramos e o tronco principal.

1. Uso Avançado do CVS Módulo 4 Foco: Gestor de Configuração e Projeto

2. Agenda Os arquivos de controle da área de trabalho Trabalhando com etiquetas Utilizando ramos e múltiplas linhas de código Exportando projetos Recursos para projetos com vários usuários Editando o repositório com o comando admin Ferramentas de auxílio ao CVS Boas práticas em Gestão de Configuração de Software

3. Os Arquivos de Controle da Área de Trabalho No módulo de administração vimos um pouco de como o CVS guarda informações no repositório Veremos agora o que o CVS armazena na cópia local Os arquivos de controle estão sob os diretórios CVS Eles são armazenados em formato texto, seguindo a convenção de fins-de-linha do sistema operacional cliente Os principais arquivos da área de trabalho são: Root : Contém a localização da raiz do repositório Repository : Tem o caminho no repositório ao qual o diretório da cópia local corresponde Entries : Lista arquivos e diretórios sob o diretório de trabalho Indica nome, revisão em uso, data da atualização, presença de conflitos e opções aderentes a arquivos (opção-k, etiqueta ou data) Tag : Registra etiquetas e datas aderentes ao diretório todo

4. Gerenciando Etiquetas O CVS permite a obtenção de qualquer revisão de arquivos mantidos sob o controle de versões Vimos que é útil obter uma revisão específica de um arquivo, por exemplo, para se reverter uma alteração Porém, é muito mais útil recuperar as revisões de arquivos que, juntas, formam um conjunto coeso O conceito que representa um conjunto coerente de revisões dentro de um projeto é a liberação Etiquetas são usadas para marcar liberações Também são usadas para marcar revisões individuais Um nome é muito mais significativo que um número de revisão

5. Uma Liberação Antes da Etiqueta

6. A Liberação Após a Etiqueta

7. As Etiquetas Virtuais BASE e HEAD O CVS disponibiliza duas etiquetas “virtuais” Revisão base: BASE A revisão na qual a cópia de trabalho está baseada É a revisão obtida pela última atualização da área Revisão cabeça: HEAD A última revisão do arquivo no repositório Leva em consideração a linha de código em uso Podem ser usadas como qualquer outra etiqueta

8. O Comando tag O comando tag aplica uma etiqueta sobre revisões de arquivos, por default, as revisões na cópia local ( BASE ) cvs [ op_glob ] tag [ op_cmd ] etiqueta [ arquivos ...] op_glob são opções globais, op_cmd são opções do comando Os argumentos são: o nome da etiqueta a ser criada e zero ou mais arquivos (e diretórios) sobre os quais ela será aplicada As opções de comando mais úteis com tag são: -b : Faz com que etiqueta seja um ramo ( branch ) -c : Não aplica a etiqueta se algum arquivo local estiver modificado -D data , -r revisão e -f : permitem especificar outras revisões -F : Move a etiqueta se ela já existe em outra revisão do arquivo -d : Apaga a etiqueta dos arquivos especificados O comando rtag é similar, porém atua só no repositório e, por default, marca as últimas revisões ( HEAD )

9. Nomes de Etiquetas Use nomes significativos e claros para etiquetas O CVS impõe restrições aos nomes de etiquetas Devem começar com letra (maiúscula ou minúscula) Podem conter letras, dígitos, hífen “-” e sublinhado “_” Sugestão de convenção para nomes de etiquetas: Todas as letras maiúsculas Separar nomes e dígitos por hífen “-” Usar sublinhado “_” no lugar de ponto “.” Exemplos: O módulo places-1.0 ganhou a etiqueta PLACES-1_0 O cvs-1.12.13 seria etiquetado CVS-1_12_13

10. Quando Aplicar Etiquetas A freqüência de aplicação de etiquetas faz parte da política de gestão de configuração do projeto Assim como as convenções de nomenclatura de etiquetas Regra geral: aplique uma etiqueta a cada estágio importante do projeto No mínimo, cada liberação deve ser marcada Outras situações onde é recomendado aplicar etiquetas: Logo após finalizar um requisito importante Logo antes de remover um recurso a pedido do cliente Logo antes de iniciar uma bateria de testes Logo antes de criar um novo ramo (veremos adiante) Logo antes de fazer a mescla de um ramo (veremos adiante)

11. Lab4-1: Aplicando Etiquetas Aplicar uma etiqueta sobre as revisões presentes em uma cópia local Verificar o comportamento da opção –c Mover uma etiqueta Aplicar uma etiqueta diretamente sobre o repositório Desafio: renomear uma etiqueta

12. Múltiplas Linhas de Código Um ramo é uma derivação da linha de código principal de um projeto, o tronco Permite que alterações sejam feitas em uma cópia à parte dos arquivos, sem afetar a linha principal O CVS implementa um ramo como uma etiqueta especial Um ramo é criado pelo comando tag , com a opção –b As revisões marcadas pela etiqueta formam a base do ramo É boa prática marcar as revisões-base com uma etiqueta normal A partir da base, alterações feitas sobre o ramo são armazenadas separadas das alterações feitas sobre o tronco A numeração das revisões no ramo é derivada das revisões-base Nomes de ramos seguem as mesmas regras que etiquetas Para diferenciar, convencionamos usar letras minúsculas Como etiquetas, é possível criar ramos sobre apenas alguns arquivos de um projeto, mas não é recomendado

13. Tronco Principal e Ramos

14. Trabalhando em um Ramo Um ramo define uma linha de código distinta Cada área de trabalho está associada a uma linha Portanto, para se trabalhar em um ramo, cria-se uma área de trabalho voltada para aquele ramo A opção –r para checkout e update permite a associação de uma cópia local a um ramo Basta especificar o nome de um ramo para a opção A opção é aderente, futuras execuções de comandos na mesma cópia local se aplicarão ao ramo Ao contrário de etiquetas comuns, ramos permitem a execução do comando commit Novas revisões serão criadas dentro do ramo utilizado

15. Mesclas de Ramos É útil ter linhas distintas de código, mas por vezes é preciso mesclar alterações entre duas linhas. Exemplos: Quando uma nova liberação está sendo desenvolvida em um ramo e se deseja propagar a correção de um defeito para o tronco Quando a nova liberação está pronta e deve se tornar a principal Uma mescla de ramos tem uma direção: o ramo origem (inalterado) e o ramo destino (conterá as modificações) Tanto o ramo origem quanto o destino podem ser o tronco Mesclas de ramos são feitas com o comando update , usando-se a opção –j ( join ou junção) Boas práticas: Aplicar uma etiqueta sobre o ramo destino antes da mescla Um ramo pode ser abandonado após uma mescla, mas não é possível nem desejável remover troncos abandonados

16. A Opção –j para update A opção –j para o comando update realiza a junção de revisões, geralmente em ramos distintos Use também –k k , para evitar expansões de palavras-chave É possível usar uma ou duas opções –j em update Com duas opções: update –j rev1 –j rev2 Toma as diferenças de rev1 para rev2 = Delta( rev1 , rev2 ) Aplica Delta( rev1 , rev2 ) sobre a revisão na cópia local, loc Pode ocorrer conflito entre Delta( rev1 , rev2 ) e Delta( rev1 , loc ) Com uma opção: update –j rev Obtém a revisão ancestral entre rev e a cópia local: anc Calcula as diferenças de anc para rev = Delta( anc , rev ) Aplica Delta( anc , rev ) sobre a revisão na cópia local, loc Pode ocorrer conflito entre Delta( anc , rev ) e Delta( anc , loc )

17. Mesclando de Ramo para Tronco Queremos tomar as diferenças entre a base do ramo e a ponta do ramo e aplicá-las sobre a ponta do tronco Faça um check-out do tronco Execute update –j ETIQ-BASE –j ramo Na figura, ETIQ-BASE é REL-2_0 e ramo é rel-2_0

18. Mesclando de Tronco para Ramo Queremos tomar as diferenças entre a base do ramo e a ponta do tronco e aplicá-las sobre a ponta do ramo Faça um check-out do ramo Execute update –j ETIQ-BASE –j HEAD Na figura, ETIQ-BASE é REL-2_0 e HEAD é 1.5

19. Mesclando de Ramo para Ramo Queremos tomar as diferenças entre a base e a ponta do ramo origem e aplicá-las sobre a ponta do ramo destino Faça um check-out do ramo destino Execute update –j ETIQ-BASE-ORIG –j ramo-dest Abaixo, ETIQ-BASE é REL-2_0 e ramo-dest é rel-2_1

20. Modelos de Funcionamento Há dois modelos de funcionamento para ramos Com a linha principal Tronco evolui sempre Ramos propagam para o tronco Ramos tornam-se obsoletos em algum ponto Com a promoção de linhas Ramos são “promovidos” à medida que evoluem Propagação é sempre para o ramo promovido Tronco e ramos antigos tornam-se obsoletos

21. Quando Criar Ramos Variações sobre um mesmo tema Crie ramos para armazenar variantes de um mesmo sistema para clientes diferentes Use ramos para guardar diferentes configurações de um mesmo sistema para servidores distintos Correção de defeitos Crie ramos para corrigir defeitos em liberações anteriores de um sistema, enquanto ele evolui Alterações experimentais Use ramos para realizar mudanças experimentais, que podem ser descartadas ou parcialmente incorporadas Grandes mudanças Crie ramos para implementar mudanças profundas no sistema, que o deixarão instável por um período longo

22. Lab4-2: Trabalhando com Ramos Criar um ramo sobre uma liberação existente Criar uma nova área de trabalho, sobre o ramo Submeter alterações no ramo Fazer uma mescla do ramo para o tronco

23. Exportando Projetos Em algumas situações, é necessário distribuir os arquivos mantidos sob controle de versões Se a empresa atua como fornecedor, pode ser preciso enviar arquivos para um cliente Os comandos checkout e update criam áreas de trabalho, com subdiretórios de controle CVS Ao exportar, queremos somente os fontes O comando export extrai arquivos para distribuição Atua diretamente no repositório cvs [ op_glob ] export [ op_cmd ] módulo ... op_glob são opções globais ( -d é a mais usada) op_cmd são opções de comando, similares a checkout As mais usadas são –D data , –r revisão e –k opção-k (p.e., -kv ) A opção –d diretório também é usada, como em checkout O argumento é o nome de um ou mais módulos

24. Lab4-3: Exportando uma Liberação Exportar uma liberação de um projeto Usar as revisões marcadas por uma etiqueta Controlar a substituição de palavras-chave na exportação

25. Recursos para Projetos com Vários Usuários Criado para o uso concorrente, o CVS oferece recursos para projetos com muitos usuários Além das capacidades já conhecidas e do modelo copia-modifica-mescla, o CVS oferece: A capacidade para funcionar em um modelo de edição exclusiva de arquivos, com uma dentre duas formas: Observando arquivos, é possível sugerir, mas não forçar, a edição exclusiva de arquivos Com o comando admin , pode-se implementar o modelo trava-modifica-destrava, para garantir a edição exclusiva A divulgação de operações como check-ins e aplicações de etiquetas, por programas configurados em modules Um comando para acompanhar a atividade dos autores

26. Observando Arquivos O CVS oferece comandos para avisar usuários quando arquivos são editados ou submetidos Esses comandos são úteis para: Monitorar as atividades de membros da equipe Acompanhar a edição de certos arquivos, diminuindo a probabilidade de mesclas Sugerir, mas não garantir, um modelo de edição exclusiva Comandos envolvidos: watch , edit e unedit Para seu funcionamento correto, é preciso configurar os arquivos administrativos notify e users

27. Mecânica da Observação Um usuário cria sua área de trabalho Ele marca alguns arquivos para observação Isso é feito com o comando cvs watch on arquivos ... A operação avisa o CVS que o arquivo será observado O gestor do projeto é em geral quem define isso O usuário se inclui na lista de observadores dos arquivos nos quais ele está interessado Ele usa o comando cvs watch add sobre os arquivos Ele e outros usuários devem usar o comando edit antes de editar um arquivo observado Os observadores serão notificados sobre a edição Ao terminar as alterações, o autor as submete ( commit ) Caso queira descartá-las, usa unedit , que reverte as mudanças e avisa os demais que o arquivo não está mais sendo editado

28. Reservando Arquivos para Edição O modelo copia-modifica-mescla é bastante efetivo para a maioria dos projetos Porém, em alguns casos, pode ser preciso usar o modelo trava-modifica-destrava Por exemplo, quando os arquivos sob o controle do CVS são binários, criados com uma ferramenta e a mescla é impossível Para implementar edição exclusiva com o CVS: Instale e configure o script rcslock , disponível na maioria das distribuições do CVS Ele deve ficar em um diretório acessível por todos os usuários e o arquivo commitinfo deve ser configurado para chamá-lo Para reservar um arquivo, use o comando admin com a opção –l Ao submeter alterações com commit , a trava será removida Para desistir da reserva sem check-in, use admin com a opção –u

29. Divulgando Operações Outra forma de auxiliar projetos com vários usuários é divulgar operações relevantes Por exemplo, check-ins e marcações de liberações Para divulgar check-ins: Configure o arquivo loginfo para enviar e-mail para uma lista, contendo a mensagem de log do check-in Para divulgar a aplicação de etiquetas: Configure o arquivo modules , usando a opção –t para especificar um programa para o envio de e-mail O programa só será invocado quando a etiqueta for aplicada com o comando rtag

30. Acompanhando a Atividade do Repositório O CVS registra a atividade sobre o repositório no arquivo administrativo history Para isso, esse arquivo deve existir e disponível para escrita pelos usuários do CVS O comando history lista a atividade do CVS cvs [ op_glob ] history [ op_cmd ] [ arquivos ...] op_glob são opções globais e op_cmd , opções de comando. As mais usadas são: -m módulo : relata o histórico somente de módulo -D data : mostra somente o histórico a partir de data O argumento são zero ou mais arquivos (ou módulos) A saída de history pode ser configurada Sua forma geral é uma tabela com tipos de operações, datas usuários e arquivos afetados

31. O Comando admin O comando admin disponibiliza várias operações administrativas sobre o repositório Algumas são perigosas, mantidas por razões históricas cvs [ op_glob ] admin [ op_cmd ] [ arquivos ...] op_glob são opções globais, op_cmd são opções do comando, as mais usadas são: -k opção-k : Redefine o modo de substituição de palavras-chave; útil quando um arquivo binário é adicionado como texto – l rev e –u rev : Trava e destrava revisões de arquivos – m rev : msg : Redefine a mensagem de log da revisão O argumento são zero ou mais arquivos ou diretórios Cuidado: admin tem comportamento recursivo por default!

32. Ferramentas para o CVS Com os conhecimentos adquiridos neste curso, é possível usar plenamente o CVS em qualquer projeto Porém, ferramentas auxiliares podem ser úteis: Para tornar as atividades mais eficientes, com interfaces gráficas Para ajudar usuários sem prática com a linha de comando Clientes gráficos: CVSGUI: WinCVS (Windows), gCVS (UNIX), MacCVS (Macintosh) Multi-plataforma, escritos em Java: jCVS e SmartCVS Linux: Cervisia e LinCVS (Qt), Pharmacy (Gnome), tkCVS (Tcl/Tk) Cliente integrado ao shell do Windows: TortoiseCVS IDEs Java com cliente CVS integrado: Eclipse, JBuilder, NetBeans Ferramentas para distribuição e acesso remoto: CVSUp, Chora, CVSviaFTP, CVSweb, jCVS Servlet, ViewCVS Conversores: rcs-to-cvs, sccs2rcs, VSS2CVS, pvcs2rcs

33. Boas Práticas em GCS Como o tema de Gestão de Configuração é amplo, há várias boas práticas e padrões para a área Livro: Software Configuration Management Patterns (Berczuk) Muitas boas práticas aplicadas ao CVS foram citadas ao longo do treinamento Manter a área de trabalho atualizada com update Usar commit de acordo com a política em vigor Aplicar etiquetas com tag : Para marcar liberações relevantes para o projeto Antes de criar um ramo e antes de uma mescla de outro ramo Criar ramos ( tag –b ) quando uma nova linha de código for necessária: versão experimental, correção de defeitos, etc. Boas práticas gerais serão vistas nos próximos slides

34. Boas Práticas: Área de Trabalho Não compartilhe áreas de trabalho Cada autor deve ter sua área de trabalho exclusiva Não altere arquivos fora das áreas de trabalho Controle a atualização de sua área de trabalho Não deixe que processos automáticos ou eventos externos atualizem a área sem a sua intervenção Mantenha a sincronia com a linha de código Atualize a área com freqüência Faça check-ins com freqüência Mas procure seguir a política da linha de código

35. Boas Práticas: Linha de Código Atribua uma política a cada linha de código Linhas mais experimentais podem ter um nível de exigência menor quando à qualidade do código Linhas mais maduras e estáveis devem ser severas Defina um dono para cada linha de código As políticas podem ser ambíguas ou pode haver uma exceção: o dono é quem resolve Tenha uma linha principal Entre linha principal e promoção de linhas, a melhor abordagem é ter uma linha principal Mantenha sempre a evolução dessa linha

36. Boas Práticas: Ramos Crie ramos só quando necessário Um ramo significa trabalho extra – tenha isso em mente e só crie ramos quando realmente necessário Não crie cópias quando se deve criar ramos Quando um ramo for necessário, use-o; não copie os arquivos para outro diretório para evoluí-los Crie ramos diante de políticas incompatíveis Versões experimentais, novos recursos, defeitos Postergue a criação de ramos Deixe a criação do ramo para o último momento: quanto menor a distância para uma mescla, melhor Crie ramos em vez de congelar a linha de código

37. Boas Práticas: Mesclas de Ramos Faça as alterações que devem ser propagadas na linha que mudou menos desde a criação do ramo Imagine uma alteração que terá que ser propagada para diversos ramos (a correção de um defeito grave) Faça essa alteração na linha que menos mudou desde que o ramo foi criado – será mais fácil propagá-la Propague as mudanças cedo e com freqüência Quanto menor a diferença entre as revisões, melhor: é maior a probabilidade de se ter uma mescla automática Peça à pessoa certa para fazer a mescla Escolha quem fez a alteração a ser propagada (origem) ou quem conhece o código que irá recebê-la (destino)

38. Boas Práticas: Compilação Código-fonte + Ferramentas = Produto Não há lugar para passos manuais Faça o check-in do código original Separe artefatos derivados do código original Use ferramentas padrão na compilação Não use ferramentas esotéricas, elas podem não existir amanhã Se possível, integre o CVS à compilação Os sistemas mais importantes podem ser integrados com o CVS: Ant: disponibiliza uma tarefa chamada cvs make: comandos CVS podem estar em regras no Makefile Compile com freqüência Guarde os logs e a saída da compilação

39. Boas Práticas: Gestão de Mudanças Acompanhe pacotes de mudanças Saiba quais arquivos mudaram em conjunto para atender uma demanda (novo recurso, correção de defeito) O CVS não oferece grande auxílio aqui, só mensagens de log Acompanhe propagações de pacotes de mudanças Saiba como os pacotes são aplicados a outras linhas de código Diferencie requisições de mudanças de pacotes de mudanças Separe o que foi pedido daquilo que foi feito para atender o pedido Atribua um dono a tudo Linha de código, documento, produto, tarefa devem ter um dono Mantenha a documentação atualizada Crie documentos só quando necessário, isso ajudará!

40. Encerramento Obrigado por participar deste treinamento! Cobrimos praticamente todos os aspectos do CVS: Dimensionamento, instalação, configuração, uso Todos os comandos (sim, vimos todos eles!) Arquivos administrativos e variáveis de ambiente Agora é um bom momento para: Tirar dúvidas Compartilhas experiências Fazer comentários, elogios e críticas Por favor, preencham os formulários de avaliação Meu contato: marden@mardenneubert.com