CVS - Slides Parte 4 - Avançado

4-1

CVS

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

Uso Avançado do CVS

Módulo 4

Foco: Gestor de Configuração e Projeto

4-2


Agenda

• Os arquivos de controle da áreade 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

4-3


Os Arquivos de Controleda Á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-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

4-5


Uma Liberação Antes da Etiqueta

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

4-6


A Liberação Após a Etiqueta

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

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

C:\ 1.1

1.2

1.3

1.4

1.3

BASE

HEAD

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

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

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

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

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

4-13


Tronco Principal e Ramos

1.1 1.3 1.4 1.51.2

1.2.2 1.2.2.1 1.2.2.2

1.2.4Ramos

1.2.4.1 1.2.4.2 1.2.4.3

1.3.2Ramo 1.3.2.1 1.3.2.2

Tronco

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

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

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

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

1.1 1.3 1.4 1.51.2

1.2.2Ramo “rel-2_0” 1.2.2.1 1.2.2.2

Tronco 1.6

REL-2_0

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

1.1 1.3 1.4 1.51.2

1.2.2Ramo “rel-2_0” 1.2.2.1 1.2.2.2

Tronco

REL-2_0

1.2.2.3

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

1.1 1.3 1.4 1.51.2

1.2.2Ramo “rel-2_0” 1.2.2.1 1.2.2.2

Tronco

REL-2_0

1.3.2Ramo “rel-2_1” 1.3.2.1 1.3.2.2

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

Linha principal

Promoção de linhas

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

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

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

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

4-25


Recursos para Projetoscom 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

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

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

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

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

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

4-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:• -kopçã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• –mrev: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!

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

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

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

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

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

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

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

4-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á!

4-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: [email protected]

Technology

CVS - Slides Parte 4 - Avançado