CVS - Slides Parte 1 - Introdução

891 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

CVS - Slides Parte 1 - Introdução

  1. 1. Introdução a Gestão de Configuração e CVS Módulo 1 Foco: Geral
  2. 2. Agenda <ul><li>O que o CVS é, o que ele não é </li></ul><ul><li>Sistemas de controle de versões, alternativas </li></ul><ul><li>A disciplina de Gestão de Configuração </li></ul><ul><li>Histórico e arquitetura geral do CVS </li></ul><ul><li>Cenários de funcionamento do CVS </li></ul><ul><li>Visita guiada ao CVS </li></ul><ul><li>Conceitos básicos </li></ul><ul><li>Outros conceitos </li></ul><ul><li>Conceitos gerais do CVS </li></ul>
  3. 3. O Que É o CVS? <ul><li>CVS significa Concurrent Versions System </li></ul><ul><ul><li>Em bom português: Sistema de Versões Concorrentes </li></ul></ul><ul><li>É um sistema de controle de versões open-source </li></ul><ul><li>Um sistema de controle de versões é usado para: </li></ul><ul><ul><li>Registrar versões de arquivos ao longo de sua evolução </li></ul></ul><ul><ul><li>Recuperar qualquer versão armazenada de um arquivo </li></ul></ul><ul><ul><li>Permitir a evolução concorrente de várias versões </li></ul></ul><ul><ul><ul><li>Daí a ênfase em “versões concorrentes” </li></ul></ul></ul><ul><li>Além disso, o CVS facilita o trabalho simultâneo de vários autores em um mesmo arquivo </li></ul><ul><ul><li>Evitando, por exemplo, que um autor sobrescreva as modificações feitas por outro </li></ul></ul>
  4. 4. O Que o CVS Não É <ul><li>Um sistema de compilação de código </li></ul><ul><li>Um sistema de acompanhamento de defeitos </li></ul><ul><li>Um sistema de controle de mudanças </li></ul><ul><li>Um sistema de automatização de testes </li></ul><ul><li>Um sistema de gestão de conteúdo </li></ul><ul><li>Um substituto para a gestão </li></ul><ul><li>Um substituto para a comunicação </li></ul><ul><li>Um substituto para a disciplina </li></ul><ul><li>Um processo de desenvolvimento </li></ul>
  5. 5. Sistemas de Controle de Versões <ul><li>Controle de Versões é definido como “o processo de armazenar e recuperar as modificações em um projeto” </li></ul><ul><li>Funcionalidades típicas de um sistema de controle de versões: </li></ul><ul><ul><li>É possível autenticar e controlar o acesso de usuários (autores) </li></ul></ul><ul><ul><li>Qualquer revisão armazenada pode ser recuperada para modificação ou apenas visualização </li></ul></ul><ul><ul><li>Diferenças entre quaisquer duas revisões podem ser visualizadas </li></ul></ul><ul><ul><li>Vários autores podem trabalhar em um mesmo arquivo, sem riscos </li></ul></ul><ul><ul><li>É possível marcar estágios relevantes na evolução do trabalho </li></ul></ul><ul><ul><li>Um projeto pode ser ramificado em linhas alternativas de trabalho </li></ul></ul><ul><ul><li>Alterações em linhas alternativas podem ser propagadas </li></ul></ul><ul><ul><li>O trabalho pode ser distribuído através de redes de qualquer porte </li></ul></ul>
  6. 6. O Que Deixar sob o Controle de Versões? <ul><li>Sempre ficam sob o controle de versões: </li></ul><ul><ul><li>Qualquer arquivo produzido por atividades desenvolvidas no decorrer de um projeto </li></ul></ul><ul><ul><ul><li>Código-fonte, modelos UML, requisitos, scripts de teste </li></ul></ul></ul><ul><ul><li>Arquivos auxiliares que não gerados automaticamente ou necessários para compilar/transformar os fontes </li></ul></ul><ul><ul><ul><li>Arquivos de compilação ( build.xml , Makefile ), configurações </li></ul></ul></ul><ul><li>Ficam fora do controle de versões: </li></ul><ul><ul><li>Arquivos facilmente gerados por compilação ou transformação </li></ul></ul><ul><ul><ul><li>Binários (executáveis, bibliotecas), documentação automática </li></ul></ul></ul><ul><li>Podem ficar sob o controle de versões: </li></ul><ul><ul><li>Arquivos que não poderiam ser gerados de forma simples </li></ul></ul><ul><ul><ul><li>Bibliotecas de terceiros, código gerado por ferramentas inacessíveis </li></ul></ul></ul><ul><ul><li>Regra geral: qualquer arquivo que não puder ser gerado facilmente às vésperas de uma liberação deve ser versionado </li></ul></ul>
  7. 7. Alternativas ao CVS <ul><li>Open-source </li></ul><ul><ul><li>RCS (Revision Control System) </li></ul></ul><ul><ul><li>SCCS (Source Code Control System) </li></ul></ul><ul><ul><li>Subversion </li></ul></ul><ul><li>Comerciais </li></ul><ul><ul><li>Microsoft Visual SourceSafe </li></ul></ul><ul><ul><li>Rational ClearCase </li></ul></ul><ul><ul><li>Borland StarTeam </li></ul></ul><ul><ul><li>Perforce </li></ul></ul>
  8. 8. Gestão de Configuração de Software <ul><li>A configuração de um sistema são as características de hardware e software que levam a um produto final </li></ul><ul><li>Gestão de configuração é o processo de acompanhar a configuração de um sistema ao longo do tempo para: </li></ul><ul><ul><li>Controlar mudanças à configuração de forma sistemática </li></ul></ul><ul><ul><li>Manter a integridade da configuração ao longo da vida do sistema </li></ul></ul><ul><li>É uma disciplina de suporte ao ciclo de vida do software </li></ul><ul><li>De forma geral, define como uma organização: </li></ul><ul><ul><li>Constrói e libera produtos </li></ul></ul><ul><ul><li>Identifica e acompanha mudanças </li></ul></ul><ul><li>Encontra-se formalmente definida em padrões como: </li></ul><ul><ul><li>IEEE Std 828-1998 e ISO/IEC TR 15846:1998 </li></ul></ul><ul><li>É parte integrante do SWEBOK </li></ul>
  9. 9. Melhores Práticas de Engenharia de Software <ul><li>Abordagens conhecidas e testadas </li></ul><ul><ul><li>Observadas em projetos que tiveram sucesso </li></ul></ul>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. 10. Fases, Disciplinas e Iterações
  11. 11. Breve História do CVS <ul><li>O RCS foi desenvolvido por Walter Tichy, da Purdue University, no início dos anos 80 </li></ul><ul><li>Em 1986, Dick Grune postou alguns shell scripts no comp.sources.unix para melhorar o RCS </li></ul><ul><ul><li>Os scripts permitiam a edição concorrente de arquivos, sem o uso de travas, daí surgindo o nome CVS </li></ul></ul><ul><li>Brian Berliner em 1989 reescreveu todo o CVS em C, mantendo as idéias de Tichy e Grune </li></ul><ul><ul><li>Entre as contribuições da nova versão estão o suporte a ramos e o uso de um repositório central </li></ul></ul><ul><li>O código-fonte do CVS foi publicado sob a licença GPL e hoje é software livre, mantido pela FSF </li></ul>
  12. 12. Arquitetura
  13. 13. Funcionamento Básico do CVS <ul><li>Eis um cenário que descreve uma sessão típica de uso do CVS, assumindo um repositório disponível: </li></ul><ul><ul><li>João é destacado para trabalhar no projeto de um novo sistema de cadastro de clientes para sua empresa </li></ul></ul><ul><ul><li>João faz um check-out do projeto, obtendo assim uma cópia de trabalho com as últimas revisões do código </li></ul></ul><ul><ul><li>João compila o código, executa o sistema e identifica um defeito no cadastro do endereço comercial </li></ul></ul><ul><ul><li>João edita um arquivo-fonte, testa novamente e verifica que corrigiu o defeito </li></ul></ul><ul><ul><li>João submete sua alteração ao repositório, incluindo um comentário que descreve o propósito da correção </li></ul></ul>
  14. 14. Ilustração do Cenário Básico
  15. 15. Um Cenário Mais Complexo <ul><li>Eis um cenário um pouco mais complexo de uso do CVS, envolvendo mais de um usuário: </li></ul><ul><ul><li>João acha um defeito na validação do cartão de crédito </li></ul></ul><ul><ul><li>Carlos, que também trabalha no projeto, implementa o suporte a uma nova bandeira de cartões de crédito </li></ul></ul><ul><ul><li>Carlos termina suas alterações e as submete </li></ul></ul><ul><ul><li>João corrige o defeito e tenta submeter suas alterações </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>João tem que atualizar sua cópia e resolver o conflito, mesclando as alterações feitas por ele e por Carlos </li></ul></ul><ul><ul><li>João submete novamente o arquivo e tem sucesso </li></ul></ul>
  16. 16. Ilustração do Cenário Complexo
  17. 17. O Modelo Copia-Modifica-Mescla <ul><li>O modelo de funcionamento do CVS é chamado “copia-modifica-mescla” </li></ul><ul><ul><li>Ele recebe este nome pela forma como autores trabalham sobre os arquivos sob controle de versões: </li></ul></ul><ul><ul><ul><li>Obtêm uma cópia da última revisão dos arquivos </li></ul></ul></ul><ul><ul><ul><li>Modificam como e quando bem quiserem </li></ul></ul></ul><ul><ul><ul><li>Ao submeter as alterações, podem encontrar conflitos; e, neste caso, devem mesclar as alterações que geraram os conflitos </li></ul></ul></ul><ul><li>Esse modelo se opõe ao “trava-modifica-destrava” </li></ul><ul><ul><li>Travas impõem um funcionamento mais restritivo: </li></ul></ul><ul><ul><ul><li>Ao obter uma cópia de trabalho, um autor trava os arquivos </li></ul></ul></ul><ul><ul><ul><li>Enquanto ele modifica os arquivos, ninguém pode alterá-los </li></ul></ul></ul><ul><ul><ul><li>Ao submeter as alterações, ele destrava os arquivos </li></ul></ul></ul>
  18. 18. Visita Guiada ao CVS <ul><li>Cenário 1 </li></ul><ul><ul><li>Fazemos o check-out de um módulo </li></ul></ul><ul><ul><li>Tomamos um arquivo e examinamos seu histórico </li></ul></ul><ul><ul><li>Editamos este arquivo na cópia de trabalho </li></ul></ul><ul><ul><li>Submetemos a modificação ao repositório </li></ul></ul><ul><ul><li>Verificamos a nova revisão no histórico do arquivo </li></ul></ul><ul><li>Cenário 2 </li></ul><ul><ul><li>Criamos outra cópia de trabalho </li></ul></ul><ul><ul><li>Submetemos uma modificação, agora desta cópia </li></ul></ul><ul><ul><li>Modificamos o mesmo arquivo na outra cópia </li></ul></ul><ul><ul><li>Tentamos submeter a modificação. O que ocorre? </li></ul></ul>
  19. 19. Conceitos Básicos de GCS <ul><li>Repositório ( Repository ) </li></ul><ul><li>Módulo ( Module , Projeto) </li></ul><ul><li>Área de trabalho ( Workspace , Sandbox , Cópia de trabalho) </li></ul><ul><li>Check-out (Retirar, Obter) </li></ul><ul><li>Check-in ( Commit , Efetivar, Submeter) </li></ul><ul><li>Revisão ( Revision ) </li></ul>
  20. 20. Repositório <ul><li>É o local onde o sistema de controle de versões armazena os históricos dos arquivos </li></ul><ul><ul><li>Pode ser um banco de dados, ou um diretório especial </li></ul></ul><ul><li>Guarda também outras informações, tais como: </li></ul><ul><ul><li>Usuários e senhas </li></ul></ul><ul><ul><li>Permissões (leitura, modificação) </li></ul></ul><ul><ul><li>Tipos dos arquivos (binário, texto) </li></ul></ul><ul><ul><li>Etiquetas e ramos </li></ul></ul><ul><ul><li>Travas (quando suportadas) e outros controles </li></ul></ul><ul><li>No CVS, o repositório é um diretório contendo: </li></ul><ul><ul><li>Módulos, cada um com os históricos de seus arquivos </li></ul></ul><ul><ul><li>Um diretório administrativo, chamado CVSROOT </li></ul></ul><ul><li>O repositório pode ser especificado para qualquer comando CVS usando-se a opção global -d </li></ul>
  21. 21. Módulo <ul><li>É uma unidade de trabalho independente, sob o controle de versões </li></ul><ul><ul><li>Está associado a um sistema, componente ou projeto </li></ul></ul><ul><li>Um módulo bem projetado pode ser obtido do repositório e utilizado de forma isolada </li></ul><ul><ul><li>Pode haver dependências entre os produtos de dois módulos: um sistema S usa um componente C </li></ul></ul><ul><li>Um módulo tem seus próprios arquivos e atributos </li></ul><ul><ul><li>Permissões, etiquetas e ramos existem por módulo </li></ul></ul><ul><li>No CVS, é um diretório sob a raiz do repositório </li></ul><ul><ul><li>Módulos mais complexos podem ser definidos no arquivo administrativo modules </li></ul></ul><ul><li>O nome do módulo é o parâmetro para checkout </li></ul>
  22. 22. Área de Trabalho <ul><li>É onde o autor guarda seus arquivos de trabalho </li></ul><ul><ul><li>Normalmente corresponde a um diretório local na estação de trabalho do autor </li></ul></ul><ul><li>Contém cópias de revisões dos arquivos no repositório, daí outro nome: cópia de trabalho </li></ul><ul><ul><li>Pode conter arquivos fora do controle de versões </li></ul></ul><ul><li>Na área de trabalho, o autor: </li></ul><ul><ul><li>Edita arquivos sob o controle de versões </li></ul></ul><ul><ul><li>Cria e adiciona novos arquivos ao controle de versões </li></ul></ul><ul><ul><li>Obtém novas revisões de arquivos no repositório </li></ul></ul><ul><ul><li>Realiza outras operações sobre o módulo, como criar etiquetas e ramos, observar alterações em arquivos </li></ul></ul>
  23. 23. Check-Out <ul><li>É a ação que traz revisões do repositório </li></ul><ul><ul><li>Quando executada pela primeira vez, cria a área de trabalho </li></ul></ul><ul><ul><li>Se executado sobre uma área de trabalho existente, atualiza as cópias dos arquivos </li></ul></ul><ul><li>Em geral, um check-out obtém as revisões mais recentes no repositório. O CVS permite também obter revisões: </li></ul><ul><ul><li>Por uma data (p.e., todas as revisões em 23/07/2005, 15:13h ) </li></ul></ul><ul><ul><li>Marcadas por uma etiqueta (p.e., revisões marcadas REL_2-1 ) </li></ul></ul><ul><ul><li>Em um ramo (p.e., últimas revisões no ramo defeitos_2-0 ) </li></ul></ul><ul><ul><li>Pelo seu número identificador (p.e., a revisão 1.2 de um arquivo) </li></ul></ul><ul><li>No CVS, um check-out não trava as revisões obtidas </li></ul><ul><li>O comando update também traz revisões do repositório </li></ul><ul><ul><li>Só pode ser usado sobre áreas de trabalho existentes </li></ul></ul>
  24. 24. Check-In <ul><li>É a ação que submete ao repositório alterações feitas sobre um ou mais arquivos </li></ul><ul><ul><li>As alterações devem ser feitas em uma área de trabalho, de onde o check-in envia as modificações </li></ul></ul><ul><li>Um check-in com sucesso sempre cria no repositório uma nova revisão para cada arquivo alterado </li></ul><ul><ul><li>A nova revisão fará parte da linha de código em uso na área </li></ul></ul><ul><li>Para que um check-in tenha sucesso, a área de trabalho deve estar atualizada em relação a sua linha de código </li></ul><ul><ul><li>Uma tentativa de check-in de um arquivo desatualizado força uma atualização da cópia e uma mescla das modificações </li></ul></ul><ul><li>No CVS, o comando commit faz o check-in de alterações </li></ul><ul><ul><li>O apelido desse comando ( ci ) faz referência ao termo check-in </li></ul></ul>
  25. 25. Revisão <ul><li>É cada um dos estágios na evolução de um arquivo sob o controle de versões </li></ul><ul><ul><li>O conjunto de revisões de um arquivo é seu histórico </li></ul></ul><ul><li>O CVS armazena revisões no seu repositório, em arquivos de histórico (arquivos RCS) </li></ul><ul><ul><li>Um arquivo de histórico tem o mesmo nome do arquivo versionado, seguido de ,v (vírgula vê) </li></ul></ul><ul><ul><li>Apenas as diferenças (deltas) entre as revisões são armazenados, não as revisões inteiras (exceto binários) </li></ul></ul><ul><li>No CVS, revisões são identificadas por uma seqüência par de números inteiros, separados por pontos </li></ul><ul><ul><li>Por exemplo, 1.2 e 1.3.2.15 são revisões válidas, 1.3.2 não é </li></ul></ul>
  26. 26. Outros Conceitos de GCS <ul><li>Mescla ( Merge ) </li></ul><ul><li>Conflito ( Conflict ) </li></ul><ul><li>Liberação ( Release , Version , Versão) </li></ul><ul><li>Etiqueta ( Tag , Label ) </li></ul><ul><li>Linha de código ( Codeline ) </li></ul><ul><li>Ramo ( Branch ) </li></ul><ul><li>Perfis envolvidos em GCS </li></ul>
  27. 27. Mescla <ul><li>É o processo de se combinar duas revisões de um arquivo, produzindo uma nova revisão </li></ul><ul><ul><li>Só faz sentido mesclar revisões de um mesmo arquivo! </li></ul></ul><ul><li>Diante de modificações independentes, o CVS tenta realizar uma mescla automática </li></ul><ul><ul><li>O algoritmo de mescla foi uma das razões da criação do CVS </li></ul></ul><ul><ul><li>Ele vê o ancestral comum e procura uma combinação das revisões </li></ul></ul><ul><li>Entretanto, a mescla falha se as modificações foram feitas em regiões próximas do arquivo </li></ul><ul><ul><li>Esta situação é chamada conflito (definido adiante) </li></ul></ul><ul><ul><li>Neste caso, o algoritmo cria um arquivo com uma mescla parcial, marcando a região problemática </li></ul></ul><ul><ul><li>O autor diante do conflito deve resolvê-lo com uma mescla manual </li></ul></ul>
  28. 28. Mescla: Ilustração
  29. 29. Conflito <ul><li>É a situação que ocorre quando uma mescla não pode ser realizada automaticamente </li></ul><ul><ul><li>O algoritmo de mescla salva uma cópia do arquivo com os trechos conflitantes de ambas as revisões </li></ul></ul><ul><ul><li>Cabe então ao autor resolver apropriadamente o conflito, produzir uma cópia consistente e submetê-la </li></ul></ul><ul><li>O CVS não tem controle sobre a mescla manual </li></ul><ul><ul><li>A única verificação que o CVS faz para evitar o check-in de arquivos parciais é a data de alteração do arquivo </li></ul></ul><ul><ul><ul><li>Ela deve ser mais recente do que o momento da mescla parcial </li></ul></ul></ul><ul><li>Ferramentas dão suporte visual à mescla manual </li></ul><ul><ul><li>Exemplo: Guiffy </li></ul></ul>
  30. 30. Liberação <ul><li>Um projeto é formado por vários arquivos </li></ul><ul><ul><li>Cada arquivo tem seu próprio histórico de evolução, mas evolui em ritmo diferente dos outros </li></ul></ul><ul><ul><li>A questão é: como identificar um conjunto de revisões em um projeto que forma um todo coerente? </li></ul></ul><ul><ul><ul><li>Podem existir vários conjuntos coerentes... </li></ul></ul></ul><ul><li>Uma liberação é um conjunto coerente de revisões que é relevante para o projeto </li></ul><ul><ul><li>Normalmente, liberações marcam etapas no ciclo de desenvolvimento de um sistema ( milestones ) </li></ul></ul><ul><ul><ul><li>Por exemplo, a versão 2.0 Beta, ou a versão 2.1 Final </li></ul></ul></ul><ul><li>Para criar uma liberação, é preciso marcar cada revisão que deve fazer parte dela </li></ul><ul><ul><li>O mecanismo usado para isso é a etiqueta, definição adiante </li></ul></ul>
  31. 31. Liberação: Antes da Marcação
  32. 32. Liberação: Após a Marcação
  33. 33. Etiqueta <ul><li>Nome que pode ser dado a uma revisão, para facilitar sua identificação </li></ul><ul><ul><li>É também chamado “revisão simbólica” ou “rótulo” </li></ul></ul><ul><li>É usada para marcar liberações, identificar revisões testadas, indicar revisões com defeito </li></ul><ul><ul><li>O nome de uma etiqueta deve descrever seu propósito </li></ul></ul><ul><li>Uma etiqueta só pode marcar uma única revisão de cada arquivo </li></ul><ul><li>É comum que uma etiqueta marque todos os arquivos de um módulo </li></ul><ul><ul><li>Entretanto, isso não é obrigatório </li></ul></ul>
  34. 34. As Etiquetas Virtuais BASE e HEAD <ul><li>O CVS disponibiliza duas etiquetas “virtuais” </li></ul><ul><li>Revisão base: BASE </li></ul><ul><ul><li>A revisão na qual a cópia de trabalho está baseada </li></ul></ul><ul><ul><li>É a revisão obtida pela última atualização da área </li></ul></ul><ul><li>Revisão cabeça: HEAD </li></ul><ul><ul><li>A última revisão do arquivo no repositório </li></ul></ul><ul><ul><li>Leva em consideração a linha de código em uso </li></ul></ul><ul><li>Podem ser usadas como qualquer outra etiqueta </li></ul>
  35. 35. Linha de Código <ul><li>É a evolução dos arquivos de um módulo </li></ul><ul><ul><li>Engloba todas as revisões dos arquivos do módulo </li></ul></ul><ul><ul><li>Uma linha de código está para um módulo assim como um histórico está para um arquivo </li></ul></ul><ul><li>A progressão das revisões em uma linha de código é linear </li></ul><ul><ul><li>Dado um instante no tempo, uma linha de código tem apenas uma revisão de cada arquivo </li></ul></ul><ul><li>Pode ser necessário criar bifurcações de uma linha de código, para permitir a evolução paralela de revisões </li></ul><ul><ul><li>Por exemplo, para se corrigir os defeitos da versão 1 de um sistema, enquanto já se trabalha na versão 2 </li></ul></ul><ul><li>Uma área de trabalho está associada a uma e somente uma linha de código </li></ul><ul><li>Todo módulo tem uma linha principal, chamada tronco </li></ul>
  36. 36. Ramo <ul><li>É uma derivação da linha de código principal </li></ul><ul><ul><li>Seu propósito é permitir a evolução paralela (concorrente) de revisões de um mesmo arquivo </li></ul></ul><ul><li>Algumas situações para o emprego de ramos: </li></ul><ul><ul><li>Criação de uma nova versão de um sistema em paralelo com correção de defeitos na versão anterior </li></ul></ul><ul><ul><li>Grande reescrita de um sistema, de longa duração, em paralelo com pequenos requisitos e/ou defeitos </li></ul></ul><ul><ul><li>Incorporação de código fornecido por um terceiro </li></ul></ul><ul><li>No CVS, ramos são tipos especiais de etiquetas </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Dentro de um histórico CVS, ramos são identificados por uma seqüência ímpar de inteiros, separados por pontos </li></ul><ul><ul><li>Por exemplo, 1.3.2 e 1.5.32.7.10 são números válidos de ramos </li></ul></ul>
  37. 37. Perfis Envolvidos em GCS <ul><li>Administrador de sistemas </li></ul><ul><ul><li>Preparação do ambiente, instalação e configuração de máquinas, sistemas operacionais, ferramentas, etc. </li></ul></ul><ul><li>Gestor de configuração </li></ul><ul><ul><li>Definição da política de GCS </li></ul></ul><ul><li>Gerente/coordenador de projeto </li></ul><ul><ul><li>Criação de projetos, definição de autores e permissões, conduz a comunicação entre os demais perfis </li></ul></ul><ul><li>Autor </li></ul><ul><ul><li>Obtenção de arquivos, submissão de modificações </li></ul></ul><ul><ul><li>Autores de nível sênior definem liberações e ramos </li></ul></ul>
  38. 38. Comandos CVS <ul><li>O CVS possui apenas um executável, que recebe comandos como parâmetro </li></ul><ul><li>Os comandos têm uma forma geral: </li></ul><ul><ul><li>cvs [ op_glob ] comando [ op_cmd ] [ args ] </li></ul></ul><ul><li>Onde: </li></ul><ul><ul><li>cvs é o nome do executável do CVS </li></ul></ul><ul><ul><li>op_glob são opções globais, que afetam todos os comandos CVS </li></ul></ul><ul><ul><li>comando é o nome ou apelido do comando invocado </li></ul></ul><ul><ul><li>op_cmd são opções específicas do comando </li></ul></ul><ul><ul><li>args são argumentos do comando, tais como arquivos sobre os quais ele opera </li></ul></ul>
  39. 39. Algumas Opções Globais <ul><li>Algumas opções globais do CVS são usadas com maior freqüência e merecem destaque: </li></ul><ul><ul><li>– d rep : Especifica o repositório utilizado, como um diretório local ou no seguinte formato: </li></ul></ul><ul><ul><ul><li>[: método :][ usuário [: senha ]@][ servidor [: porta ]] raiz </li></ul></ul></ul><ul><ul><li>– n : Não realiza nenhuma operação, útil para testes </li></ul></ul><ul><ul><li>– q e –Q : Suprime a impressão de mensagens na saída </li></ul></ul><ul><ul><li>– r : Faz com que todos os arquivos de trabalho sejam criados para somente leitura </li></ul></ul><ul><ul><li>– z nível : Comprime a comunicação com o servidor </li></ul></ul>
  40. 40. Recursos Gerais do CVS (1) <ul><li>Repositório como um sistema de arquivos normal </li></ul><ul><ul><li>Permite configurações de permissões usando recursos do sistema operacional </li></ul></ul><ul><ul><li>Viabiliza inspeção e edição direta de históricos </li></ul></ul><ul><li>Comportamento recursivo </li></ul><ul><ul><li>A grande maioria dos comandos se aplica recursivamente a diretórios </li></ul></ul><ul><ul><li>Simplifica o uso de comandos como update e commit </li></ul></ul><ul><li>Opções aderentes à área de trabalho </li></ul><ul><ul><li>Algumas opções ficam gravadas na área de trabalho </li></ul></ul><ul><ul><li>Não precisam ser especificas a cada novo comando </li></ul></ul>
  41. 41. Recursos Gerais do CVS (2) <ul><li>Substituição de palavras-chave </li></ul><ul><ul><li>Informações sobre as revisões podem ser incluídas dentro de arquivos mantidos sob o controle do CVS </li></ul></ul><ul><ul><li>Expressões como $Revision$ , $Date$ e $Author$ são expandidas para os valores correspondentes </li></ul></ul><ul><ul><li>Pode ser controlada por arquivo (a chamada opção–k) </li></ul></ul><ul><li>Arquivos ignorados por padrões de nome </li></ul><ul><ul><li>Arquivos que não serão nunca adicionados ao controle de versões podem ser ignorados pelos comandos CVS </li></ul></ul><ul><li>Configuração de arquivos por padrões de nome </li></ul><ul><ul><li>Algumas características dos arquivos podem ser configuradas de acordo com seus padrões de nome </li></ul></ul>
  42. 42. Recursos Gerais do CVS (3) <ul><li>Observação de arquivos </li></ul><ul><ul><li>Um usuário pode marcar arquivos para que ele seja notificado quando esses arquivos forem editados </li></ul></ul><ul><ul><li>A marcação é feita pelo comando watch ; a edição tem que ser indicada com o comando edit </li></ul></ul><ul><li>Especificação de revisões </li></ul><ul><ul><li>Pode ser feita por número de revisão, etiqueta ou data </li></ul></ul><ul><ul><li>As opções –r (para números e etiquetas) e –D (para datas) são reconhecidas por diversos comandos </li></ul></ul><ul><li>Consulta a variáveis de ambiente </li></ul><ul><ul><li>Alguns comportamentos do CVS podem ser controlados por variáveis de ambiente do cliente </li></ul></ul>

×