cvs - slides parte 1 - introdução

1-1

CVS

www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert

Introdução a Gestão de Configuração e CVS

Módulo 1

Foco: Geral

1-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

1-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

1-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

1-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

1-6


O Que Deixar sob oControle 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

1-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

1-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

1-9


Melhores Práticas deEngenharia de Software

• Abordagens conhecidas e testadas– Observadas em projetos que tiveram sucesso

Usarcomponentes

Verificar aqualidade

Desenvolver iterativamente

Controlar mudanças

Desenvolver iterativamente

Controlar mudanças

Usarcomponentes

Modelarvisualmente

Verificar aqualidade

Gerenciarrequisitos

1-10


Fases, Disciplinas e Iterações

1-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

1-12


Arquitetura

Repositório

LAN

`

Terminal

Internet

Servidor

1

2

3

1-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

1-14


Ilustração do Cenário Básico

Cria cópia

João : Autor

: Cópia de trabalho

Obtém alterações

: Repositório

Edita arquivo

Cria revisão

Check-out

Check-in

1-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

1-16


Ilustração do Cenário Complexo

João : Autor\\João\Trabalho : Cópia de trabalho

Edita arquivo

Carlos : Autor\\Carlos\Trabalho : Cópia de trabalho

Edita arquivo

: Repositório

Cria revisão

Check-in

Obtém alterações

Check-in

Obtém alterações

Falha: cópia desatualizada

Atualiza

Atualiza

Mescla alterações

Check-in

Obtém alterações

Cria revisão

1-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

1-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?

1-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)

1-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

1-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

1-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

`

C:\

1-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

C:\

1-24


Check-In

• É a ação que submete ao repositórioalteraçõ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

C:\

1-25


Revisão

• É cada um dos estágios na evoluçãode 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

é

1.1

1-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

1-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

1-28


Mescla: Ilustração

C:\ 1.1

1.2

1.3

1.4

1.3'

Mescla

1.4' 1.5

Atualização

Check-in

1-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

1-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

2.0 Beta

1-31


Liberação: Antes da Marcação

1.1

1.2

Estado.java

1.1

1.2

1.3

1.4

Pais.java

1.1

1.2

1.3

1.4

Cidade.java

1.1

1.2

1.3

1.4

Teste.java

1.5

1.6

1.5

1-32


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

1.1

1.2

Estado.java

1.1

1.2

1.3

1.4

Pais.java

1.1

1.2

1.3

1.4

Cidade.java

1.1

1.2

1.3

1.4

Teste.java

1.5

1.6

1.5

2.1 Final

1-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

3.2 Estável

1-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

C:\ 1.1

1.2

1.3

1.4

1.3

BASE

HEAD

1-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

1.1 1.3 1.4 1.51.2A

1.1 1.3 1.41.2B

V.1.0 V.2.0

1-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

/bugfix

1-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

1-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

1-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

1-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

1-41



• 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

1-42



• 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

cvs - slides parte 1 - introdução

Technology