O documento introduz conceitos básicos de gestão de configuração e do sistema de controle de versões CVS. Explica que o CVS permite o trabalho concorrente em arquivos, armazenando versões anteriores. Também define termos como repositório, módulo, área de trabalho, check-out, check-in e revisão.

1. Introdução a Gestão de Configuração e CVS Módulo 1 Foco: Geral

2. Agenda O que o CVS é, o que ele não é Sistemas de controle de versões, alternativas A disciplina de Gestão de Configuração Histórico e arquitetura geral do CVS Cenários de funcionamento do CVS Visita guiada ao CVS Conceitos básicos Outros conceitos Conceitos gerais do CVS

3. O Que É o CVS? CVS significa Concurrent Versions System Em bom português: Sistema de Versões Concorrentes É um sistema de controle de versões open-source Um sistema de controle de versões é usado para: Registrar versões de arquivos ao longo de sua evolução Recuperar qualquer versão armazenada de um arquivo Permitir a evolução concorrente de várias versões Daí a ênfase em “versões concorrentes” Além disso, o CVS facilita o trabalho simultâneo de vários autores em um mesmo arquivo Evitando, por exemplo, que um autor sobrescreva as modificações feitas por outro

4. O Que o CVS Não É Um sistema de compilação de código Um sistema de acompanhamento de defeitos Um sistema de controle de mudanças Um sistema de automatização de testes Um sistema de gestão de conteúdo Um substituto para a gestão Um substituto para a comunicação Um substituto para a disciplina Um processo de desenvolvimento

5. Sistemas de Controle de Versões Controle de Versões é definido como “o processo de armazenar e recuperar as modificações em um projeto” Funcionalidades típicas de um sistema de controle de versões: É possível autenticar e controlar o acesso de usuários (autores) Qualquer revisão armazenada pode ser recuperada para modificação ou apenas visualização Diferenças entre quaisquer duas revisões podem ser visualizadas Vários autores podem trabalhar em um mesmo arquivo, sem riscos É possível marcar estágios relevantes na evolução do trabalho Um projeto pode ser ramificado em linhas alternativas de trabalho Alterações em linhas alternativas podem ser propagadas O trabalho pode ser distribuído através de redes de qualquer porte

6. O Que Deixar sob o Controle de Versões? Sempre ficam sob o controle de versões: Qualquer arquivo produzido por atividades desenvolvidas no decorrer de um projeto Código-fonte, modelos UML, requisitos, scripts de teste Arquivos auxiliares que não gerados automaticamente ou necessários para compilar/transformar os fontes Arquivos de compilação ( build.xml , Makefile ), configurações Ficam fora do controle de versões: Arquivos facilmente gerados por compilação ou transformação Binários (executáveis, bibliotecas), documentação automática Podem ficar sob o controle de versões: Arquivos que não poderiam ser gerados de forma simples Bibliotecas de terceiros, código gerado por ferramentas inacessíveis Regra geral: qualquer arquivo que não puder ser gerado facilmente às vésperas de uma liberação deve ser versionado

7. Alternativas ao CVS Open-source RCS (Revision Control System) SCCS (Source Code Control System) Subversion Comerciais Microsoft Visual SourceSafe Rational ClearCase Borland StarTeam Perforce

8. Gestão de Configuração de Software A configuração de um sistema são as características de hardware e software que levam a um produto final Gestão de configuração é o processo de acompanhar a configuração de um sistema ao longo do tempo para: Controlar mudanças à configuração de forma sistemática Manter a integridade da configuração ao longo da vida do sistema É uma disciplina de suporte ao ciclo de vida do software De forma geral, define como uma organização: Constrói e libera produtos Identifica e acompanha mudanças Encontra-se formalmente definida em padrões como: IEEE Std 828-1998 e ISO/IEC TR 15846:1998 É parte integrante do SWEBOK

9. Melhores Práticas de Engenharia de Software Abordagens conhecidas e testadas Observadas em projetos que tiveram sucesso Usar componentes Verificar a qualidade Desenvolver iterativamente Controlar mudanças Desenvolver iterativamente Controlar mudanças Usar componentes Modelar visualmente Verificar a qualidade Gerenciar requisitos

10. Fases, Disciplinas e Iterações

11. Breve História do CVS O RCS foi desenvolvido por Walter Tichy, da Purdue University, no início dos anos 80 Em 1986, Dick Grune postou alguns shell scripts no comp.sources.unix para melhorar o RCS Os scripts permitiam a edição concorrente de arquivos, sem o uso de travas, daí surgindo o nome CVS Brian Berliner em 1989 reescreveu todo o CVS em C, mantendo as idéias de Tichy e Grune Entre as contribuições da nova versão estão o suporte a ramos e o uso de um repositório central O código-fonte do CVS foi publicado sob a licença GPL e hoje é software livre, mantido pela FSF

12. Arquitetura

13. Funcionamento Básico do CVS Eis um cenário que descreve uma sessão típica de uso do CVS, assumindo um repositório disponível: João é destacado para trabalhar no projeto de um novo sistema de cadastro de clientes para sua empresa João faz um check-out do projeto, obtendo assim uma cópia de trabalho com as últimas revisões do código João compila o código, executa o sistema e identifica um defeito no cadastro do endereço comercial João edita um arquivo-fonte, testa novamente e verifica que corrigiu o defeito João submete sua alteração ao repositório, incluindo um comentário que descreve o propósito da correção

14. Ilustração do Cenário Básico

15. Um Cenário Mais Complexo Eis um cenário um pouco mais complexo de uso do CVS, envolvendo mais de um usuário: João acha um defeito na validação do cartão de crédito Carlos, que também trabalha no projeto, implementa o suporte a uma nova bandeira de cartões de crédito Carlos termina suas alterações e as submete João corrige o defeito e tenta submeter suas alterações João é avisado que já existe no repositório uma nova revisão para um dos arquivos que ele modificou e sua submissão falha João tem que atualizar sua cópia e resolver o conflito, mesclando as alterações feitas por ele e por Carlos João submete novamente o arquivo e tem sucesso

16. Ilustração do Cenário Complexo

17. O Modelo Copia-Modifica-Mescla O modelo de funcionamento do CVS é chamado “copia-modifica-mescla” Ele recebe este nome pela forma como autores trabalham sobre os arquivos sob controle de versões: Obtêm uma cópia da última revisão dos arquivos Modificam como e quando bem quiserem Ao submeter as alterações, podem encontrar conflitos; e, neste caso, devem mesclar as alterações que geraram os conflitos Esse modelo se opõe ao “trava-modifica-destrava” Travas impõem um funcionamento mais restritivo: Ao obter uma cópia de trabalho, um autor trava os arquivos Enquanto ele modifica os arquivos, ninguém pode alterá-los Ao submeter as alterações, ele destrava os arquivos

18. Visita Guiada ao CVS Cenário 1 Fazemos o check-out de um módulo Tomamos um arquivo e examinamos seu histórico Editamos este arquivo na cópia de trabalho Submetemos a modificação ao repositório Verificamos a nova revisão no histórico do arquivo Cenário 2 Criamos outra cópia de trabalho Submetemos uma modificação, agora desta cópia Modificamos o mesmo arquivo na outra cópia Tentamos submeter a modificação. O que ocorre?

19. Conceitos Básicos de GCS Repositório ( Repository ) Módulo ( Module , Projeto) Área de trabalho ( Workspace , Sandbox , Cópia de trabalho) Check-out (Retirar, Obter) Check-in ( Commit , Efetivar, Submeter) Revisão ( Revision )

20. Repositório É o local onde o sistema de controle de versões armazena os históricos dos arquivos Pode ser um banco de dados, ou um diretório especial Guarda também outras informações, tais como: Usuários e senhas Permissões (leitura, modificação) Tipos dos arquivos (binário, texto) Etiquetas e ramos Travas (quando suportadas) e outros controles No CVS, o repositório é um diretório contendo: Módulos, cada um com os históricos de seus arquivos Um diretório administrativo, chamado CVSROOT O repositório pode ser especificado para qualquer comando CVS usando-se a opção global -d

21. Módulo É uma unidade de trabalho independente, sob o controle de versões Está associado a um sistema, componente ou projeto Um módulo bem projetado pode ser obtido do repositório e utilizado de forma isolada Pode haver dependências entre os produtos de dois módulos: um sistema S usa um componente C Um módulo tem seus próprios arquivos e atributos Permissões, etiquetas e ramos existem por módulo No CVS, é um diretório sob a raiz do repositório Módulos mais complexos podem ser definidos no arquivo administrativo modules O nome do módulo é o parâmetro para checkout

22. Área de Trabalho É onde o autor guarda seus arquivos de trabalho Normalmente corresponde a um diretório local na estação de trabalho do autor Contém cópias de revisões dos arquivos no repositório, daí outro nome: cópia de trabalho Pode conter arquivos fora do controle de versões Na área de trabalho, o autor: Edita arquivos sob o controle de versões Cria e adiciona novos arquivos ao controle de versões Obtém novas revisões de arquivos no repositório Realiza outras operações sobre o módulo, como criar etiquetas e ramos, observar alterações em arquivos

23. Check-Out É a ação que traz revisões do repositório Quando executada pela primeira vez, cria a área de trabalho Se executado sobre uma área de trabalho existente, atualiza as cópias dos arquivos Em geral, um check-out obtém as revisões mais recentes no repositório. O CVS permite também obter revisões: Por uma data (p.e., todas as revisões em 23/07/2005, 15:13h ) Marcadas por uma etiqueta (p.e., revisões marcadas REL_2-1 ) Em um ramo (p.e., últimas revisões no ramo defeitos_2-0 ) Pelo seu número identificador (p.e., a revisão 1.2 de um arquivo) No CVS, um check-out não trava as revisões obtidas O comando update também traz revisões do repositório Só pode ser usado sobre áreas de trabalho existentes

24. Check-In É a ação que submete ao repositório alterações feitas sobre um ou mais arquivos As alterações devem ser feitas em uma área de trabalho, de onde o check-in envia as modificações Um check-in com sucesso sempre cria no repositório uma nova revisão para cada arquivo alterado A nova revisão fará parte da linha de código em uso na área Para que um check-in tenha sucesso, a área de trabalho deve estar atualizada em relação a sua linha de código Uma tentativa de check-in de um arquivo desatualizado força uma atualização da cópia e uma mescla das modificações No CVS, o comando commit faz o check-in de alterações O apelido desse comando ( ci ) faz referência ao termo check-in

25. Revisão É cada um dos estágios na evolução de um arquivo sob o controle de versões O conjunto de revisões de um arquivo é seu histórico O CVS armazena revisões no seu repositório, em arquivos de histórico (arquivos RCS) Um arquivo de histórico tem o mesmo nome do arquivo versionado, seguido de ,v (vírgula vê) Apenas as diferenças (deltas) entre as revisões são armazenados, não as revisões inteiras (exceto binários) No CVS, revisões são identificadas por uma seqüência par de números inteiros, separados por pontos Por exemplo, 1.2 e 1.3.2.15 são revisões válidas, 1.3.2 não é

26. Outros Conceitos de GCS Mescla ( Merge ) Conflito ( Conflict ) Liberação ( Release , Version , Versão) Etiqueta ( Tag , Label ) Linha de código ( Codeline ) Ramo ( Branch ) Perfis envolvidos em GCS

27. Mescla É o processo de se combinar duas revisões de um arquivo, produzindo uma nova revisão Só faz sentido mesclar revisões de um mesmo arquivo! Diante de modificações independentes, o CVS tenta realizar uma mescla automática O algoritmo de mescla foi uma das razões da criação do CVS Ele vê o ancestral comum e procura uma combinação das revisões Entretanto, a mescla falha se as modificações foram feitas em regiões próximas do arquivo Esta situação é chamada conflito (definido adiante) Neste caso, o algoritmo cria um arquivo com uma mescla parcial, marcando a região problemática O autor diante do conflito deve resolvê-lo com uma mescla manual

28. Mescla: Ilustração

29. Conflito É a situação que ocorre quando uma mescla não pode ser realizada automaticamente O algoritmo de mescla salva uma cópia do arquivo com os trechos conflitantes de ambas as revisões Cabe então ao autor resolver apropriadamente o conflito, produzir uma cópia consistente e submetê-la O CVS não tem controle sobre a mescla manual A única verificação que o CVS faz para evitar o check-in de arquivos parciais é a data de alteração do arquivo Ela deve ser mais recente do que o momento da mescla parcial Ferramentas dão suporte visual à mescla manual Exemplo: Guiffy

30. Liberação Um projeto é formado por vários arquivos Cada arquivo tem seu próprio histórico de evolução, mas evolui em ritmo diferente dos outros A questão é: como identificar um conjunto de revisões em um projeto que forma um todo coerente? Podem existir vários conjuntos coerentes... Uma liberação é um conjunto coerente de revisões que é relevante para o projeto Normalmente, liberações marcam etapas no ciclo de desenvolvimento de um sistema ( milestones ) Por exemplo, a versão 2.0 Beta, ou a versão 2.1 Final Para criar uma liberação, é preciso marcar cada revisão que deve fazer parte dela O mecanismo usado para isso é a etiqueta, definição adiante

31. Liberação: Antes da Marcação

32. Liberação: Após a Marcação

33. Etiqueta Nome que pode ser dado a uma revisão, para facilitar sua identificação É também chamado “revisão simbólica” ou “rótulo” É usada para marcar liberações, identificar revisões testadas, indicar revisões com defeito O nome de uma etiqueta deve descrever seu propósito Uma etiqueta só pode marcar uma única revisão de cada arquivo É comum que uma etiqueta marque todos os arquivos de um módulo Entretanto, isso não é obrigatório

34. 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

35. Linha de Código É a evolução dos arquivos de um módulo Engloba todas as revisões dos arquivos do módulo Uma linha de código está para um módulo assim como um histórico está para um arquivo A progressão das revisões em uma linha de código é linear Dado um instante no tempo, uma linha de código tem apenas uma revisão de cada arquivo Pode ser necessário criar bifurcações de uma linha de código, para permitir a evolução paralela de revisões Por exemplo, para se corrigir os defeitos da versão 1 de um sistema, enquanto já se trabalha na versão 2 Uma área de trabalho está associada a uma e somente uma linha de código Todo módulo tem uma linha principal, chamada tronco

36. Ramo É uma derivação da linha de código principal Seu propósito é permitir a evolução paralela (concorrente) de revisões de um mesmo arquivo Algumas situações para o emprego de ramos: Criação de uma nova versão de um sistema em paralelo com correção de defeitos na versão anterior Grande reescrita de um sistema, de longa duração, em paralelo com pequenos requisitos e/ou defeitos Incorporação de código fornecido por um terceiro No CVS, ramos são tipos especiais de etiquetas A diferença é que um ramo pode marcar mais de uma revisão por arquivo: ele marca todas as revisões de uma linha de código Dentro de um histórico CVS, ramos são identificados por uma seqüência ímpar de inteiros, separados por pontos Por exemplo, 1.3.2 e 1.5.32.7.10 são números válidos de ramos

37. Perfis Envolvidos em GCS Administrador de sistemas Preparação do ambiente, instalação e configuração de máquinas, sistemas operacionais, ferramentas, etc. Gestor de configuração Definição da política de GCS Gerente/coordenador de projeto Criação de projetos, definição de autores e permissões, conduz a comunicação entre os demais perfis Autor Obtenção de arquivos, submissão de modificações Autores de nível sênior definem liberações e ramos

38. Comandos CVS O CVS possui apenas um executável, que recebe comandos como parâmetro Os comandos têm uma forma geral: cvs [ op_glob ] comando [ op_cmd ] [ args ] Onde: cvs é o nome do executável do CVS op_glob são opções globais, que afetam todos os comandos CVS comando é o nome ou apelido do comando invocado op_cmd são opções específicas do comando args são argumentos do comando, tais como arquivos sobre os quais ele opera

39. Algumas Opções Globais Algumas opções globais do CVS são usadas com maior freqüência e merecem destaque: – d rep : Especifica o repositório utilizado, como um diretório local ou no seguinte formato: [: método :][ usuário [: senha ]@][ servidor [: porta ]] raiz – n : Não realiza nenhuma operação, útil para testes – q e –Q : Suprime a impressão de mensagens na saída – r : Faz com que todos os arquivos de trabalho sejam criados para somente leitura – z nível : Comprime a comunicação com o servidor

40. Recursos Gerais do CVS (1) Repositório como um sistema de arquivos normal Permite configurações de permissões usando recursos do sistema operacional Viabiliza inspeção e edição direta de históricos Comportamento recursivo A grande maioria dos comandos se aplica recursivamente a diretórios Simplifica o uso de comandos como update e commit Opções aderentes à área de trabalho Algumas opções ficam gravadas na área de trabalho Não precisam ser especificas a cada novo comando

41. Recursos Gerais do CVS (2) Substituição de palavras-chave Informações sobre as revisões podem ser incluídas dentro de arquivos mantidos sob o controle do CVS Expressões como $Revision$ , $Date$ e $Author$ são expandidas para os valores correspondentes Pode ser controlada por arquivo (a chamada opção–k) Arquivos ignorados por padrões de nome Arquivos que não serão nunca adicionados ao controle de versões podem ser ignorados pelos comandos CVS Configuração de arquivos por padrões de nome Algumas características dos arquivos podem ser configuradas de acordo com seus padrões de nome

42. Recursos Gerais do CVS (3) Observação de arquivos Um usuário pode marcar arquivos para que ele seja notificado quando esses arquivos forem editados A marcação é feita pelo comando watch ; a edição tem que ser indicada com o comando edit Especificação de revisões Pode ser feita por número de revisão, etiqueta ou data As opções –r (para números e etiquetas) e –D (para datas) são reconhecidas por diversos comandos Consulta a variáveis de ambiente Alguns comportamentos do CVS podem ser controlados por variáveis de ambiente do cliente