Curso de CVS - Parte 3 - Uso Básico

Copyright© 2005, Marden Neubert

3-1

CVS

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

Uso Básico do CVS

Módulo 3

Foco: Autor

Neste módulo veremos o uso básico do CVS, cobrindo aquelas atividades que são realizadas na grande maior parte do tempo. Elas incluem a obtenção de revisões do repositório, a submissão de alterações, a comparação de diferenças, consultas a históricos e configurações do cliente. O foco deste módulo é o autor, aquele usuário que edita arquivos no repositório, como um participante de projetos. O autor pode representar um programador, um webmaster ou um escritor.


3-2


Agenda

• Configurando acesso ao repositório• Obtendo arquivos do repositório• Descartando uma cópia local• Submetendo alterações: quando e como• Atualizando a área de trabalho• Adicionando, apagando e movendo arquivos• Verificando status e históricos de arquivos• Inspecionando diferenças entre revisões• Usando palavras-chave• Configurando o cliente CVS

Este slide mostra nossa agenda para este módulo do treinamento, voltado para o uso básico do CVS.


3-3


Configurando o Acesso a um Repositório

• Os comandos CVS dependem de um repositório para executar: alguns apenas o consultam, outros o alteram

• A localização do repositório deve ser especificada para todos os comandos. O formato é o seguinte:– [:método:][usuário[:senha]@][servidor[:porta]]raiz

• O CVS procura a especificação das seguintes formas:– Na opção global –d. Ela pode ser especificada na linha de comando do CVS ou no arquivo .cvsrc, como veremos adiante

– No arquivo Root dentro dos diretórios CVS na área de trabalho• Apesar de ser possível, não invoque comandos especificando uma opção –d em uma área configurada para um repositório diferente

– No variável de ambiente $CVSROOT

• As fontes mencionadas são buscadas na ordem listada

Já percebemos que um repositório, local ou remoto, é essencial para a execução de todos os comandos CVS. Mesmo aqueles que não alteram o repositório, o consultam para algum propósito. Também já sabemos qual é formato para se especificar a localização de um repositório e vimos quais são os métodos disponíveis.

Este slide lista a forma pela qual o CVS busca essa especificação. Ele usa a primeira especificação que ele encontrar. O primeiro lugar consultado é a opção global –d, que pode tanto ser usada na linha de comando do CVS quanto incluída no arquivo de configuração .cvsrc, que tem o mesmo valor de se usar a opção na linha de comando.

O segundo lugar consultado é o arquivo Root dentro dos diretórios controle da área de trabalho, aqueles nomeados CVS. Isso faz com que seja conveniente usar os comandos CVS dentro de uma área de trabalho: não é necessário especificar o repositório a todo momento, já que é raro se trocar de repositório. Aqui vale uma observação: se usarmos a opção –d apontando para um repositório diferente em um comando dentro de uma área de trabalho, ele executará sobre o repositório dado por –d. Esse provavelmente não é o comportamento esperado, pois pode misturar arquivos de dois repositórios diferentes em uma mesma área de trabalho. Portanto, é melhor evitar essa ação.

Por fim, o último local consultado é a variável de ambiente $CVSROOT. Ela é consultada depois dos arquivos da área de trabalho, portanto não há problemas em se ter essa variável apontando para um repositório e se fazer o check-out de outro. Dentro da área de trabalho criada, não épreciso se preocupar: o repositório correto será consultado.


3-4


Obtendo Arquivos do Repositório

• Há duas motivações principais para se obter arquivos de um repositório

• Para consultá-los, editá-los e submeter alterações, o que é feito a partir de uma área de trabalho– Se a área ainda não foi criada, usa-se checkout, que também pode ser usado sobre uma área existente

– Se a área já existe, o mais indicado é utilizar-se o comando update

• Para distribuí-los, o que não cria nem requer a existência de uma área de trabalho– Para isso, usa-se o comando export, visto adiante

Na introdução a gestão de configuração, aprendemos que não se alteram arquivos diretamente no repositório. Portanto, para trabalharmos em um projeto sob controle de versões, é preciso obter os arquivos que se encontram no repositório. Há duas motivações principais para se fazer isso. A primeira é porque queremos consultar, editar e submeter alterações sobre esses arquivos, criando, portanto, novas revisões dos mesmos no repositório. Para isso, é preciso uma área de trabalho, o locam onde trabalhamos sobre os arquivos. Esse é o caso mais comum para quem trabalha em projetos. Nesse caso, o CVS nos oferece dois comandos: checkout, para quando a área de trabalho ainda não existe (checkout cria a área) e update, para quando a área já existe e queremos sincronizá-la com o repositório.

Outra motivação para se obter arquivos de um repositório é para distribuí-los. Este é o caso de quando, por exemplo, é preciso enviar arquivos a um cliente, ou executar um script automático de compilação sobre os arquivos. Para esses casos, o CVS oferece o comando export, que veremos no próximo módulo do curso.


3-5


Arquivos e Revisões Obtidos

• Ao obter arquivos, informamos quais arquivos e quais revisões desejamos trazer

• Em relação aos arquivos:– O mais comum é trazermos todo um módulo– É possível trazer subdiretórios ou até arquivos específicos de um módulo

• Em relação às revisões:– É mais freqüente pedirmos as revisões mais recentes– É possível obter revisões marcadas por uma etiqueta, criadas até uma certa data ou as últimas em um ramo• Todas essas alternativas são opções para checkout e update

Quando obtemos arquivos de um repositório, não trazemos todos os históricos dos arquivos no repositório. Precisamos informar quais arquivos queremos e em quais revisões desses arquivos estamos interessados.

Em relação aos arquivos, o normal é pedirmos um módulo inteiro. Como vimos um módulo corresponde em geral a um projeto (os nomes são até sinônimos na nomenclatura do CVS) e éuma unidade de trabalho independente. Porém, o CVS nos permite trazer apenas subdiretórios de um módulo, ou até arquivos específicos, tanto quando a área de trabalho já existe (update) e quando ela ainda não existe (checkout).

Já em relação às revisões, o mais freqüente é solicitarmos as revisões mais recentes dos arquivos nos quais estamos interessados. Porém, em algumas situações específicas, podemos querer obter outras revisões e o CVS nos permite isso. Por exemplo, é possível obter as revisões marcadas por uma etiqueta, ou criadas até uma certa data (para restaurar o estado do projeto naquela data). Também é possível pedir as últimas revisões em um ramo (reveja a definição de ramo no módulo de introdução). O CVS permite até especificar revisões com base no seu número, apesar de essa ser uma opção usada com muito menor freqüência. Todas as essas alternativas com revisões são opções que podemos usar com os comandos checkout e update.


3-6


O Comando checkout

• O comando checkout cria uma nova área de trabalho ou atualiza uma área existente

• cvs [op_glob] checkout [op_cmd] módulos...– op_glob são opções globais do CVS, a principal é –d– op_cmd são opções específicas para checkout, vistas adiante– módulos... são um ou mais nomes de módulos, de subdiretórios ou de arquivos sob a raiz do repositório, que serão obtidos

• Se a área não existe, para cada módulo especificado, checkout cria um diretório onde o comando foi chamado– O novo diretório é a raiz da área de trabalho e seu nome énormalmente o mesmo do módulo especificado

– Os arquivos criados têm permissão de escrita, a não ser que a opção global –r seja usada ou $CVSREAD seja definida

• Quando usado sobre uma área existente, tem o mesmo comportamento que update com a opção de comando -d

O comando checkout, como já sabemos, é usado para se criar uma área de trabalho ou, mais raramente, atualizar uma área existente. O formato do comando é mostrado neste slide.

O funcionamento de checkout é o seguinte. Se a área de trabalho ainda não existe (o caso mais comum), o comando irá criar um novo diretório para cada módulo especificado, no diretório onde ele foi chamado. Cada novo diretório é uma área de trabalho e debaixo dele encontram-se os arquivos do módulo correspondente. O nome do diretório é o mesmo do módulo, a não ser que uma opção seja usada (vista adiante). Os arquivos criados por checkout têm permissão de escrita, a não ser que a opção global do CVS –r seja usada, ou a variável de ambiente $CVSREAD esteja definida.

No caso mais raro de ser usado em uma área de trabalho existente, checkout funciona como o comando update com a opção –d. O comando update será visto logo em seguida.

O comando checkout pode ser abreviado como co.


3-7


Principais Opções de checkout

• Principais opções de comando para checkout:– -P: Não cria diretórios vazios na área de trabalho– -d outro_dir: Cria a área de trabalho sob o diretório outro_dir e não usa o nome do módulo

– -D data e -r revisão: Obtém as revisões especificadas por data ou revisão (número ou etiqueta). Aderentes

– -f: Com -D ou -r, força a obtenção das últimas revisões de arquivos que não casam com as especificações

– -j revisão: Mescla revisões: vista no próximo módulo– -c e -s: Não obtém arquivos, apenas lista módulos no repositório; a opção -s mostra o status do módulo

Este slide mostra algumas opções mais usadas com checkout. A opção –P é uma das mas úteis para checkout, por um motivo que já vimos no curso. Como o CVS não tem comandos para manipular diretórios, não é possível apagar diretórios que foram removidos ou renomeados. Com isso, a não ser que se edite diretamente o repositório, é comum que, com o tempo, muitos diretórios antigos apareçam vazios. Se a opção –P não for usada, esses diretórios são criados na área de trabalho.

Outra opção interessante é –d, que faz com que a área de trabalho seja criada em um diretório com o nome diferente do módulo. Ela é interessante quando queremos criar, em um mesmo local, duas cópias de trabalho de um mesmo módulo (cada uma trabalhando sobre um ramo diferente, por exemplo).

As opções –D e –r são usadas para se especificar revisões a serem obtidas. –D permite que uma data seja especificada (vários formatos de datas são suportados): as revisões obtidas são aquelas que existiam no repositório naquela data. Já–r permite que uma etiqueta ou um número de revisão seja especificado. Um ramo também pode ser especificado por –r pois, no CVS, um ramo é um tipo especial de etiqueta. Portanto, quando se quer criar uma cópia local para se trabalhar em um ramo diferente do tronco, a opção usada é –r. Essas opções são aderentes, isso quer dizer que comandos executados posteriormente sobre a área de trabalho (tal como update) manterão essas opções, como se elas tivessem sido especificadas na linha de comando.

A opção –f é útil somente com –D ou –r. Ela é usada para forçar que todos os arquivos no repositório sejam obtidos. Se um arquivo não casa com as especificações dadas por –D (ele foi criado depois da data) ou –r (a etiqueta não foi aplicada sobre ele), ele não será trazido por checkout, a não ser que –f seja utilizada.

A opção –j é usada para mesclar revisões. Nós a veremos somente no módulo avançado.

As opções –c e –s são diferentes, pois elas fazem com que nenhum arquivo seja obtido do repositório. Elas também dispensam a especificação de um módulo para checkout. Elas fazem com que o comando liste os módulos disponíveis no repositório, mas somente aqueles mencionados no arquivo administrativo modules. A opção –s mostra também o status do módulo, como definido em modules.


3-8


Descartando uma Área de Trabalho

• Uma área que não é mais usada pode ser descartada– Como o CVS não trava arquivos para edição, isso pode ser feito simplesmente removendo o diretório da área

– Perigo: alterações ainda não submetidas são perdidas

• Para isso, o CVS disponibiliza o comando release, que verifica se alterações pendentes de check-in na área

• cvs [op_glob] release [op_cmd] diretórios...– op_cmd: a principal opção do comando é –d. Se especificada, release apaga os arquivos da área; o default é mantê-los

– diretórios...: uma ou mais raízes de áreas de trabalho; o comando deve ser chamado de logo acima delas

• Na saída, release imprime uma mensagem para cada arquivo que não estava em sincronia com o repositório

Uma área de trabalho é um diretório comum na máquina cliente. Portanto, uma área que não émais usada pode ser descartada se simplesmente a removermos. O perigo disso é que alterações ainda não submetidas com check-in podem ser perdidas. Para a conveniência do usuário, o CVS disponibiliza o comando release, que verifica se a cópia local está fora de sincronia com o repositório. O formato desse comando é dado neste slide. A opção mais relevante é –d, que faz com que os arquivos da área sejam apagados. Na saída, release imprime uma mensagem para cada arquivo que está fora de sincronia:

U arquivo ou P arquivo: há uma revisão mais nova no repositório.

A arquivo: O arquivo foi adicionado a partir da cópia local, mas a alteração ainda não foi efetivada repositório. Isso acontece quando se faz um add mas não um commit. ATENÇÃO! Se a cópia for removida, o arquivo será perdido.

R arquivo: O arquivo foi removido da cópia de trabalho, mas essa alteração não foi efetivada no repositório. ATENÇÃO! Se a área for removida, o arquivo continuará existindo no repositório.

M arquivo: O arquivo foi modificado na cópia local. ATENÇÃO! Se a cópia for removida, as alterações serão perdidas.

? arquivo: O arquivo existe na área de trabalho, mas não no repositório. ATENÇÃO! O repositório não conhece o arquivo, se a cópia for removida, ele será perdido.


3-9


Alterando Arquivos na Cópia Local

• Os arquivos podem ser editados na cópia local como em qualquer diretório normal

• Para arquivos de texto, use seu editor preferido– Adicione-os como texto ao repositório– Não se preocupe com fins-de-linha, o CVS os converte no servidor, para evitar problemas entre plataformas

• Para arquivos binários, use uma ferramenta correspondente ao tipo (.pdf, .doc, .gif, etc)– Adicione-os como arquivos binários ao repositório (-kb)– O CVS não tentará mesclas; resolva eventuais conflitos comparando as revisões manualmente

Uma cópia local é como qualquer outro diretório, portanto, os arquivos podem ser editados láassim como você o faz normalmente. Para arquivos texto, use o editor preferido para a linguagem em uso. Adicione-o como texto ao repositório (o default) e não se preocupe com os fins-de-linhase o arquivo for editado em plataformas UNIX e Windows. O repositório CVS converte fins-de-linha em arquivos texto para um formato único no repositório e converte para o formato apropriado no cliente.

Já para arquivos binários, use a ferramenta mais apropriada e os adicione como binários ao repositório. Isso evita que sejam feitas conversões que podem danificar o arquivo (fins de linha e palavras-chave). Isso também fará com que o CVS não tente mesclar revisões desse arquivo; você deverá resolver conflitos manualmente usando a ferramenta correspondente.


3-10


Submetendo Alterações

• Para que as alterações feitas na cópia local sejam visíveis para outros, elas devem ser submetidas– A submissão ou check-in propaga as alterações para o repositório, criando novas revisões dos arquivos

• Uma questão freqüente de programadores em projetos de software é: quando submeter alterações?– Se o check-in é feito muito cedo, ele pode introduzir erros de execução (pela falta de testes) ou até de compilação

– Se o check-in é feito muito tarde, as alterações demoram a ficar disponíveis para os demais e aumenta o risco de conflitos

• A regra geral é: realize uma unidade de trabalho por vez, conclua-a e a submeta como um todo para o repositório

• A definição de unidade de trabalho varia de acordo com a política da linha de código em uso, mas, no mínimo:– A alteração deve manter o código do projeto compilando– A alteração deve ter passado por testes unitários básicos

As alterações feitas em uma cópia de trabalho não são vistas por mais ninguém além do usuário dono da cópia até que elas sejam submetidas ao repositório. Quando uma submissão de alterações (o chamado check-in) é feita, ela cria novas revisões dos arquivos modificados.

Muitas vezes já vi programadores (e eu mesmo) no seguinte dilema, diante um projeto de software: quando (ou com qual freqüência) submeter alterações ao repositório? Se isso for feito muito cedo em uma tarefa (ou com muita freqüência ao longo de um projeto), corro o risco de submeter alterações incompletas, que causem falhas nos testes do sistema ou até erros de compilação (se, por exemplo, enviamos uma modificação incompleta).

Por outro lado, se demoro muito a fazer um check-in, nesse período os outros usuários vão ter que esperar muito para ver minhas alterações e aumento o risco de estar diante de um conflito quando decidir submetê-las. Qual é a saída?

A regra geral que uso é tentar fazer as alterações em “unidades de trabalho”: algo coeso e com um objetivo claro como, por exemplo, uma pequena requisição de melhoria, uma correção de defeito, uma evolução específica. Devemos fazer uma unidade de trabalho por vez (evitar de trabalhar em duas ao mesmo tempo) e submeter uma alteração por vez. O comando commit do CVS favorece isso, permitindo que usemos uma única mensagem de log para um conjunto de alterações submetidas juntas.

A questão é que a definição de unidade de trabalho varia de acordo com a política em vigor na linha de código em uso. Como regras gerais eu uso: 1) o código deve continuar compilando depois de feita a alteração e 2) o programador deve ter feito e executado testes unitários básicos sobre ela. Como toda regra, elas têm exceções. Por exemplo, no início de um projeto, é claro que a instabilidade do código é menor, sendo até aceitável fazer check-ins de código que nem compila, para não se segurar muitas alterações na cópia local. À medida que o projeto evolui, as regras ficam mais rígidas. Por exemplo, pouco antes de uma liberação, um check-in que quebre a compilação é totalmente inaceitável.


3-11


O Comando commit

• O comando commit submete arquivos alterados na área de trabalho, criando novas revisões

• cvs [op_glob] commit [op_cmd] [arquivos...]– op_glob são opções globais do CVS e op_cmd são específicas de commit, que serão vistas adiante

– Zero ou mais arquivos (ou diretórios) podem ser dados; commitinspeciona diretórios recursivamente

• O comportamento de commit é o seguinte:– Identifica, dentre os arquivos, quais foram alterados na cópia local– Dentre os alterados, verifica se todos estão atualizados

• Se algum arquivo está desatualizado, termina em erro, pede update

– Abre um editor pedindo uma mensagem de log para o check-in– Cria uma nova revisão para cada arquivo alterado

O comando usado para submeter alterações ao repositório é commit. Para cada arquivo alterado processado por commit, uma nova revisão será criada no repositório. O formato de commit émostrado neste slide. No próximo slide, veremos as principais opções de comando reconhecidas por commit. O argumento para commit é zero ou mais arquivos e/ou diretórios que serão inspecionados. Se nenhum parâmetro for informado, o diretório de onde o comando foi invocado éprocessado.

O comando commit inspeciona os arquivos especificados como argumento (diretórios são processados recursivamente) e verifica quais deles foram alterados na cópia local. Dentre os alterados, commit verifica se todos estão atualizados com o repositório. Daí, commit abre um editor de textos pedindo uma mensagem de log (um comentário) sobre o check-in e propaga as alterações para o repositório, criando uma nova revisão para cada arquivo alterado.

Vamos agora às exceções. Se um arquivo alterado inspecionado por commit encontra-se desatualizado com relação ao repositório, commit exibe uma mensagem de erro pedindo para se atualizar a cópia local (como vimos no exemplo no início do treinamento) e termina em erro. Se a opção –m é passada para commit especificando uma mensagem de log (ou a opção –F, passando um nome de um arquivo com uma mensagem), o editor de textos não é chamado.


3-12


Principais Opções de commit

• As principais opções para commit são:– -m mensagem e -F arquivo: Especificam uma mensagem ou um arquivo contendo uma mensagem• A mensagem (chamada de log) é usada para documentar a operação no repositório, funcionando como um comentário

– -f: Força a criação de uma nova revisão mesmo que os arquivos especificados não tenham sido alterados

– -r revisão: Cria uma nova revisão, que pode ser um nome de ramo ou um número de revisão (implica -f)• Se revisão for um número, deve ser maior que qualquer outro número de revisão existente e a nova revisão terá tal número

• Exemplo: executando cvs commit -r 3.0 na raiz do módulo, será criada uma nova revisão para cada arquivo, numerada 3.0

Este slide mostra as principais opções para commit. A mais usada, de longe, é –m mensagem, que especifica uma mensagem de log para o commit. Com essa opção, a mensagem é acatada e o editor não é aberto. O mesmo acontece quando se usa –F, que recebe como parâmetro um nome de arquivo contendo a mensagem de log.

A opção –f pode ser usada quando se quer forçar a criação de uma nova revisão, mesmo que o arquivo não tenha sido alterado.

Já a opção –r força a criação da nova revisão especificada. Se revisão for um ramo, o commit

criará uma nova revisão naquele ramo (funciona como se estivéssemos trabalhando naquele ramo, mas o mais comum é se fazer um check-out do ramo, como veremos o próximo módulo). Se revisão for um número de revisão, esse número tem que ser no tronco (dois números separados por um ponto) e ser maior do qualquer outro número existente para os arquivos sendo submetidos. Caso afirmativo, as novas revisões criadas terão esse número. Isso é útil para se trazer todas as revisões do repositório para um valor significativo, por exemplo, 2.0 ou 3.0. Como números de revisão são em geral detalhes internos do CVS (o que aparece mais para nós são as etiquetas), essa opção é mais uma curiosidade.


3-13


Lab3-1: Submetendo Alterações

• Alterar um arquivo e submeter alterações sem especificar uma mensagem na linha de comando

• Testar o comportamento recursivo de commit• Forçar o check-in de uma revisão, mesmo sem alterações

• Atribuir um novo número derevisão a todos os arquivosde um módulo

Neste lab, exercitaremos o comando commit. Veja o arquivo lab-3.doc nos materiais do aluno para maiores detalhes.


3-14


Atualizando a Área de Trabalho

• É uma boa prática manter a área de trabalho sempre atualizada com o repositório– Permite que as últimas alterações sejam vistas– Evita que se trabalhe sobre revisões antigas (conflitos)

• O comando que atualiza uma cópia é update• cvs [op_glob] update [op_cmd] [arquivos...]

– op_glob são globais, op_cmd são vistas adiante– O argumento são zero ou mais arquivos (e diretórios), que serão inspecionados e atualizados, se necessário

• A saída produzida por update mostra, para cada arquivo processado, o status da atualização

A área de trabalho é sua visão do projeto, portanto, ela deve estar sempre sincronizada com o repositório. Caso contrário, você poderá estar usando uma versão mais antiga do projeto e, ainda pior, alterando arquivos que já foram modificados no repositório, o que produzirá um conflito adiante.

O comando mais usado para se atualizar uma cópia local é update. Como já foi visto, checkout

também pode ser usado para isso, mas update é o comando criado para esse propósito, é mais conveniente, flexível e mais recomendado. A sintaxe de update é mostrada neste slide. Além das opções globais e específicas, update recebe zero ou mais arquivos (ou diretórios) como parâmetro. Cada um deles será inspecionado no repositório e, caso necessário, atualizado. Assim como commit e vários outros comandos, update tem comportamento recursivo: se um diretório for especificado, todos os arquivos e diretórios abaixo serão inspecionados. No slide seguinte veremos as opções mais importantes para update.

O comando update pode fazer diversas alterações na cópia local, tais como atualizar arquivos, criar e remover diretórios, tentar mesclas automáticas. Para cada arquivo afetado pela sua execução, update imprime uma linha na saída, mostrando a ação tomada. Veremos adiante o formato da saída de update.


3-15


Principais Opções de update

• As opções mais usadas com update são:– -d: Faz com que novos diretórios no repositório sejam criados na cópia local; é sempre recomendável usar -d

– -P: Assim como em checkout, -P faz com que diretórios vazios não sejam criados na cópia local

– -D data e -r revisão: Atualiza a cópia com revisões especificadas por data ou revisão (número/etiqueta). São opções aderentes

– -f: Com -D ou -r, força a obtenção das últimas revisões de arquivos que não casam com as especificações

– -A: Limpa opções aderentes na cópia local– -C: Sobrescreve alterações na cópia local– -I padrão e -W espec: Usa padrão e espec para ignorar ou configurar de arquivos com base em padrões de nome

– -j revisão: Faz a mescla de revisão com a cópia local (avançado)

Este slide mostra as opções mais usadas com update. Sem dúvida, as opções mais úteis são –d e –P. Se a opção –d não for especificada, o CVS não cria novos diretórios na cópia local, somente atualiza arquivos em diretórios já existentes. Este comportamento certamente não deveria ser o default, mas é. Portanto, é sempre útil especificar –d para update, tanto que, para não esquecer, éconveniente configurar essa opção como default no arquivo .cvsrc, que veremos ao fim deste módulo. Outra opção interessante é –P, que tem a mesma função que em checkout: faz com que diretórios vazios não sejam criados na cópia local.

As opções –D, –r e –f têm o mesmo significado que com checkout. Convém lembrar que –D e –r

são opções aderentes, isto é, uma vez usadas, as especificações continuam sendo usadas em chamadas subseqüentes de update.

Para limpar opções aderentes, deve ser usada a opção –A. A opção –C é perigosa, mas pode ser útil: se um arquivo estiver modificado na cópia local e houver uma versão mais recente no repositório (potencial conflito), a cópia local é sobrescrita.

As opções –I e –W permitem a especificação de mais padrões para arquivos ignorados e embaladores, complementando os arquivos cvsignore e cvswrappers.

A opção –j é usada para fazer mesclas de revisões. Ela pode usada para reverter uma revisão, isto é, voltar um arquivo para uma revisão anterior (quando, por exemplo, desistimos de uma alteração já submetida para o repositório). Ela também é útil quando se quer propagar as alterações de um ramo para outro (isto será visto com mais detalhe no módulo avançado).


3-16


Formato da Saída de update

• Cada linha tem o formato X arquivo, onde X representa um dos seguintes status para arquivo:– U ou P: O arquivo foi atualizado com relação ao repositório

• U indica atualização completa, P indica que um patch foi feito– A: O arquivo foi adicionado a partir da cópia local (com add), mas isso ainda não foi submetido (com commit)

– R: O arquivo foi removido a partir da cópia local (com remove), mas isso ainda não foi efetivado (commit)

– M: O arquivo foi modificado na cópia local e:• Não havia modificações no repositório; a cópia local não é alterada ou• As modificações no repositório foram mescladas com sucesso (sem conflitos) e o resultado está agora na cópia local

– C: O arquivo foi modificado na cópia local e no repositório e, ao se tentar a mescla, ocorreu um conflito. A mescla deve ser manual

– ?: O arquivo não corresponde a nada no repositório: ele deveria ser adicionado (add) ou ignorado (cvsignore ou –I)

Cada linha da saída de update mostra o status de um arquivo no processo de atualização. O status é dado pelo primeiro caractere da linha, o nome do arquivo é mostrado em seguida. Os caracteres de status são mostrados neste slide. U e P indicam que o arquivo foi atualizado: U indica uma atualização completa (ou o arquivo mudou muito ou ele ainda não existia na cópia local) e P diz que a atualização foi feita por um patch, o que permite que menos banda de rede seja usada. A indica que o arquivo foi adicionado a partir da cópia local com o comando add, mas ainda falta submeter essa alteração com commit. Situação análoga é dada por R, só que para arquivos removidos a partir da cópia local.

O status M indica que o arquivo estava modificado na cópia local e uma das seguintes situações ocorreu: 1) não havia modificações no repositório (nesse caso, a cópia local não é alterada) e 2) havia modificações no repositório, mas elas foram mescladas com sucesso com as alterações locais. O resultado da mescla foi escrita sobre o arquivo na cópia local (um back-up desse arquivo é salvo no formato .#arquivo.revisão).

O status C, por outro lado, diz que havia alterações na cópia local e no repositório, mas a mescla falhou, diante de um conflito. A cópia local do arquivo passa a conter a mescla parcial e o arquivooriginal é salvo no formato .#arquivo.revisão. A mescla deve ser feita manualmente.

O status ? indica que o arquivo está na cópia local, mas não corresponde a nenhum arquivo no repositório. Pode ser um arquivo novo, que deve ser adicionado, ou um arquivo que nunca serácolocado no repositório e deveria ser ignorado. Neste último caso, configure isso usando cvsignore ou a opção –I.


3-17


Revertendo Alterações

• Uma situação comum é desejarmos voltar um arquivo para uma revisão antiga. Isso ocorre:– Porque a alteração não corrigiu um erro, ou criou outro– Quando um requisito alterado é cancelado

• Há duas formas de usar update para reverter uma alteração (p.e., voltar da 1.3 para a 1.2):– Usar a opção –r para obter a revisão desejada e especificar –p, que faz com que o resultado seja escrito na saída padrão:• cvs update –r 1.2 –p Country.java > Country.java

– Usar a opção –j para fazer uma mescla entre as duas revisões, de forma a produzir a 1.2 (atenção à ordem das opções):• cvs update –j 1.3 –j 1.2 Country.java

• Um check-in será feito, criando a revisão 1.4, igual à 1.2

Algumas vezes, uma alteração tem que ser desfeita. Em alguns casos, o erro é do programador, que tentou corrigir um erro e não conseguiu ou, pior, introduziu um novo erro. Em outro casos, éum problema de requisitos: a demanda foi feita e, depois, o cliente “mudou” de idéia. Qualquer que seja o caso, o CVS pode ajudar a reverter um arquivo na cópia local para uma revisão anterior.

Há duas formas de se fazer isso, ambas usando update. Vamos supor que queremos voltar da revisão 1.3 para a 1.2 de um arquivo. Assumimos que 1.3 é a última revisão no repositório e que a cópia local está atualizada. A primeira opção é usar a opção –r para obter a revisão desejada, juntamente com –p, que faz com que os dados obtidos pelo comando sejam impressos na saída padrão e não escritos no arquivo. Redirecionamos a saída padrão para o arquivo (usando “>”) e temos a revisão desejada. Note que o arquivo local terá o conteúdo da revisão 1.2, mas estará com o status de modificado na cópia local, pois é diferente da última revisão no repositório, 1.3.

A outra opção é mais sofisticada. Usamos a opção –j para pedir uma mescla entre as duas revisões. Como veremos em maior detalhe no módulo avançado, quando usamos duas opções –j

com update, o comando calcula as alterações da primeira opção (no caso 1.3) para a segunda opção (1.2 pelo exemplo) e as aplica sobre a cópia local. Como a cópia local tem a revisão 1.3, ao aplicar essas alterações, obteremos exatamente 1.2. O arquivo local também estará modificado em relação ao repositório.

Em ambos os casos, é preciso fazer um novo check-in para efetivar a nova revisão no repositório. Ela será 1.4, mas terá o mesmo conteúdo de 1.2.


3-18


Lidando com Conflitos

• Um conflito surge quando o CVS não consegue realizar uma mescla automaticamente

• O CVS tenta uma mescla automática quando o arquivo em questão permite isso (veja cvswrappers) e:– Executamos update para atualizar a cópia local, onde um arquivo foi modificado e há uma revisão mais nova no repositório

– Executamos update com a opção –j para mesclar duas revisões• O algoritmo de mescla do CVS funciona linha a linha

– Se as revisões mescladas diferem em linhas distantes do arquivo, o algoritmo automático terá sucesso

– Caso contrário, há um conflito; o algoritmo produzirá um resultado intermediário, um arquivo com marcações para a mescla manual

– Em ambos os casos, a cópia local do arquivo é salva em back-up• Para resolver um conflito, busque pelas marcações, edite o arquivo, mantendo o conteúdo correto, e faça o check-in– Com arquivos binários, abra e edite as revisões na ferramenta

Como foi comentado na introdução, um conflito acontece quando o algoritmo automático de mescla não funciona. Isso pode acontecer porque o arquivo em questão não permite mescla (por exemplo, ele binário, como vimos ao conhecer o arquivo administrativo cvswrappers). Se o arquivo é texto e permite mesclas, o algoritmo ainda sim pode falhar, se as diferenças entre as revisões forem muito próximas. Como o algoritmo funciona linha-a-linha, ele consideraráperigoso realizar a mescla automática e pedirá para que ela seja feita manualmente. Falhe ou não falhe o algoritmo, o arquivo original é mantido em um back-up, para consulta futura.

Se um conflito ocorreu em um arquivo texto, o arquivo resultante é uma mescla parcial, com marcações indicando os trechos do conflito. O autor deve usar um editor de textos para identificar esses trechos e manter o conteúdo correto. Se o conflito ocorreu porque o arquivo não pode sofrer mesclas (por exemplo, é binário), deve-se usar uma ferramenta apropriada para abrir as duas revisões conflitantes e criar uma nova revisão que contemple as alterações em ambas.

No próximo lab, exercitaremos uma situação de conflito e veremos como resolvê-la.


3-19


Lab3-2: Atualizando a Cópia Local

• Utilizar opções aderentes com update• Tentar submeter alterações com opções aderentes

• Limpar opções aderentes da cópia local• Reverter uma alteração• Realizar uma mescla automática

Neste lab, exercitaremos o comando update. Consulte o material do aluno.


3-20


Adicionando Arquivos

• O comando add adiciona ao repositório um novo arquivo ou diretório, presente na cópia local– Ao decidir quais arquivos devem ser colocados sob o controle de versões, valem as regras já apresentadas

• cvs [op_glob] add [op_cmd] arquivos...– op_glob são opções globais, op_cmd são opções de comando:

• -k modo: define o modo default de substituição de palavras-chave• -m mensagem: especifica uma mensagem de criação (comentário)

– O argumento é um ou mais arquivos (ou diretórios) a serem adicionados ao repositório

• Ao contrário de outros comandos, add não é recursivo– Antes de um arquivo ser adicionado, seu diretório deve ser– É possível usar coringas (*.java), que são expandidos pelo shell

• Arquivos processados por add ficam programados para adição: a confirmação só ocorre com commit

Se queremos adicionar um projeto inteiro ao CVS, o comando a ser usado é import. Mas, se jáestamos trabalhando em um projeto e é preciso criar mais um arquivo? Para isso existe o comando add. Ele adiciona ao repositório um novo arquivo, que deve estar presente na área de trabalho, exatamente no diretório onde ele deve ficar. Ao decidir que arquivos colocar sob o controle do CVS, lembre-se das regras discutidas no início do treinamento: evite guardar arquivos gerados automaticamente e outros que podem ser obtidos facilmente de uma fonte externa segura.

O formato de add é mostrado neste slide. As opções de comando são apenas duas: -k modo, que define o modo default de substituição de palavras-chave para o arquivo (por exemplo, -k b para arquivos binários); e –m mensagem, que especifica uma mensagem de criação para o arquivo (ao contrário de commit, add não abre um editor se a mensagem não for especificada). Como argumento, add recebe um ou mais arquivos e diretórios que serão adicionados ao repositório.

Um diferença importante de add para os demais comandos: add não é recursivo. Isso quer dizer que, chamando add passando um diretório como parâmetro, os arquivos e subdiretórios abaixo dele não serão adicionados automaticamente. Ao contrário, só aquele diretório é adicionado.

Além disso, antes de adicionar um arquivo (ou subdiretório), o diretório onde ele se encontra jádeve ter sido adicionado. Isso porque, quando um diretório é adicionado, add cria nele os subdiretórios de controle chamados CVS. Quando um arquivo é adicionado, o CVS procura por esse subdiretório no diretório onde o arquivo está; se ele não encontra, termina em erro. Uma dica: não crie diretórios chamados CVS na cópia local, isso pode confundir o CVS durante o add.

Apesar de add não ser recursivo, é possível usar recursos do sistema operacional para tornar a adição de arquivos mais conveniente. Por exemplo, é possível usar coringas (*.java, *.doc, etc.) para adicionar mais de um arquivo em um mesmo diretório, sem ter que citar todos os nomes.

Um detalhe importante sobre add: os arquivos processados por ele ficam apenas programados para adição. O repositório não receberá os arquivos (e demais usuários não os verão) até que o comando commit tem que ser chamado sobre os arquivos para confirmar sua inclusão.


3-21


Removendo Arquivos

• O comando remove apaga arquivos do repositório– Os históricos não são apagados, pois deve ser possível recuperar revisões anteriores; eles são movidos para o diretório Attic

• cvs [op_glob] remove [op_cmd] [arquivos...]– op_glob são opções globais, op_cmd são opções de comando:

• -f: Apaga o arquivo da cópia de trabalho e então executa o comando• -l e -R: Opções que permitem controlar a recursividade

– O argumento são zero ou mais arquivos (e diretórios)• Antes de se chamar remove, o arquivo tem que ser apagado da cópia local, a não ser que –f seja usado

• O comando remove é recursivo por default– Perigo se –f for usado: força uma remoção recursiva

• Assim como add, remove não confirma a remoção do arquivo no repositório; isso deve ser feito com commit

Para se remover um ou mais arquivos do repositório, o comando usado é remove. Na verdade, remove registra que o arquivo foi removido no momento de sua execução, mas não apaga seu histórico, pois deve ser possível recuperar revisões anteriores do arquivo. O que o CVS faz émover o histórico para o subdiretório Attic, no repositório, indicando que ele não está mais na versão mais recente do módulo.

O formato do comando remove é dado neste slide. As opções de comando mais importantes são: –f, que força com que o arquivo seja removido, apagando-o da cópia de trabalho e as opções-padrão para controle de recursividade: –l (desliga o comportamento recursivo) e –R (mantém o comportamento recursivo). O argumento para remove são zero ou mais arquivos (ou diretórios) a serem removidos.

O uso normal de remove é, antes de chamá-lo, identificar que arquivos devem ser removidos, apagá-los da cópia local e só então chamar o comando. Ele identificará os arquivos apagados da cópia local e os removerá do repositório. Se a opção –f for chamada, todos os arquivos especificados para remove serão apagados da cópia local e removidos do repositório, mesmo que ainda existam na cópia local. Em geral, é melhor não usar essa opção.

Um fato curioso é que remove é recursivo por default, assim como os demais comandos, ao passo que add não é. Como normalmente remove só afeta arquivos que foram apagados da cópia local, isso não é problema. O perigo é se a opção –f for usada: se um dos argumentos para remove for um diretório, ocorrerá uma remoção recursiva de arquivos e diretórios. Portanto, o preferível énunca usar –f e, se usá-lo, combiná-lo com –l para inibir o comportamento recursivo.

Assim como ocorre com add, remove não efetiva a remoção do arquivo no repositório, somente a deixa programada. A remoção deve ser confirmada com commit.


3-22


Abortando e Ressuscitando Arquivos

• É possível cancelar a adição e a remoção de arquivos antes que commit seja chamado

• Abortando a adição de um arquivo– Cenário: Criei um arquivo na cópia local, programei sua adição com add e desisti da adição

– Solução: Apago o arquivo da cópia local e executo remove sobre ele: a adição é abortada

• Ressuscitando um arquivo– Cenário: Apaguei o arquivo da cópia local e desisti da remoção– Solução: Executo update, o arquivo será restaurado– Cenário: Apaguei o arquivo da cópia local, programei sua remoção com remove e desisti do processo

– Solução: Executo add sobre o arquivo, ele é ressuscitado

O CVS permite que arquivos que estavam programados para adição sejam “abortados” e arquivos que estavam programados para remoção sejam “ressuscitados”. Deixando questões éticas e religiosas à parte, essas opções são interessantes se mudamos de idéia antes de fazer o commit. Este slide mostra 3 possíveis cenários, um no qual um arquivo adicionado é abortado e dois onde uma remoção é cancelada. Em todos esses cenários, o commit ainda não foi realizado e não fica nenhum registro da operação no repositório.


3-23


Movendo ou RenomeandoArquivos e Diretórios

• O CVS não possui operações para mover ou renomeararquivos e diretórios– Usando somente comandos do cliente, essas operações são feitas combinando-se uma remoção e uma adição

– Outra opção seria editar diretamente o repositório, como vimos no módulo de administração (nem sempre possível ou necessário)

• Movendo ou renomeando um arquivo– Mova ou renomeie o arquivo na cópia local, execute remove e depois add, comente a operação nas mensagens de commit

– Preserva o histórico do arquivo original e as liberações antigas, mas não deixa registros da movimentação

• Movendo ou renomeando um diretório– Mova ou renomeie o diretório na cópia local, execute remove e add para os arquivos internos. Use –P com update e checkout

– Tem as mesmas vantagens e desvantagens do caso com arquivos

Relembrando o que foi visto no módulo de administração, o CVS não possui operações para mover (o mesmo que renomear) arquivos e diretórios. Outras ferramentas de controle de versões conseguem registrar essas operações porque guardam revisões de diretórios, não só de arquivos. Para o ClearCase, por exemplo, renomear um arquivo em um diretório é equivalente a criar uma nova revisão do diretório. O mesmo para remover e adicionar. Com os recursos do comandos CVS, a única alternativa é remover os arquivos e depois adicioná-los com o novo nome ou a nova localização. Há ainda a opção de editar o repositório diretamente, mas essa operação é mais complicada, exige acesso privilegiado ao repositório, pode ter efeitos colaterais e, no geral, não vale o esforço.

Enfim, vejamos então como fazer essas operações. Para mover ou renomear um arquivo, faça a alteração na cópia local, execute remove para remover o nome antigo, e depois add, para adicionar o novo nome. Use commit para confirmar a operação e coloque comentários nas mensagens de log explicando o que foi feito. Com isso, o histórico do arquivo original épreservado (pois históricos de arquivos removidos não são apagados) e liberações antigas ainda podem ser restauradas. A parte ruim é que não fica nenhum registro que o arquivo novo tem uma ligação com o antigo.

Para diretórios, o processo é análogo. Mova ou renomeie o diretório e faça remove, add e commit

para todos os arquivos debaixo dele. Lembre-se de usar a opção -P com update e checkout para evitar que os diretórios antigos (agora vazios) continuem aparecendo na cópia local.


3-24


Lab3-3: Movimentando Arquivos e Diretórios

• Tentar adicionar um arquivo sem antes adicionar o diretório pai

• Abortar a adição de um arquivo• Ressuscitar um arquivo• Mover um arquivo de diretório• Renomear um diretório• Desafio: como “reencarnar” um arquivo (isto é, restaurá-lo depois de um commit já foi feito)?– Veja como restaurar uma revisão anterior– Note que, quando um arquivo é removido, uma revisão “morta” é criada

Neste laboratório veremos mais detalhes sobre como adicionar, remover e renomear arquivos e diretórios. Consulte o material do aluno para mais informações.

A última tarefa é um desafio: como “reencarnar” um arquivo já apagado com commit? A dica é se lembrar de como restaurar uma revisão anterior de um arquivo.


3-25


Verificando o Status de Arquivos

• O comando status é uma forma simples e rápida de verificar o estado dos arquivos na cópia local

• cvs [op_glob] status [op_cmd] [arquivos...]– op_glob são opções globais e op_cmd são opções de comando; a principal opção de status é:• -v: Exibe informações sobre etiquetas aplicadas nos arquivos

– O argumento são zero ou mais arquivos a serem examinados

• Usando status, é possível identificar, para um arquivo:– O número da última revisão no repositório e a revisão local– Se ele está modificado, desatualizado ou tem mescla pendente– As opções aderentes aplicadas sobre ele (data, etiqueta, opção-k)

• A saída de status exibe um conjunto de informações para cada arquivo inspecionado

Com freqüência é preciso verificar a quantas andam os arquivos na nossa cópia local: se estão atualizados, desatualizados, modificados e se há mesclas pendentes. Para isso, um comando simples e rápido é status. O formato deste comando é mostrado no slide. Além das opções –l e –R

que controlam a recursividade e se aplicam a quase todos os comandos, a única opção de status é–v, que faz com que sejam exibidas informações sobre etiquetas aplicadas sobre os arquivos examinados. O argumento, assim como em outros comandos, é zero ou mais arquivos ou diretórios. Se nenhum argumento for especificado, o diretório corrente é usado.

Na saída, status imprime o status do arquivo na cópia local, de acordo com a lista abaixo. Também são mostradas informações sobre opções aderentes, tais como datas (opção –D), número de revisão ou etiqueta (opção –r) e modo de substituição de palavras-chave (opção –k).

Up-to-date: O arquivo é idêntico à última revisão no repositório.

Locally Modified: O arquivo foi modificado e as alterações ainda não foram submetidas.

Locally Added: O arquivo foi adicionado por add, mas essa alteração ainda não foi efetivada.

Locally Removed: O arquivo foi removido por remove, mas a alteração ainda não foi efetivada.

Needs Checkout: Uma nova revisão foi criada no repositório, o arquivo precisa ser atualizado.

Needs Patch: Similar a “Needs Checkout”, o servidor enviará um patch, não uma cópia completa.

Needs Merge: O arquivo foi alterado localmente e existe uma revisão mais nova no repositório; uma mescla será tentada no próximo update.

Unresolved Conflict: Outro arquivo com o mesmo nome foi adicionado ao repositório. O arquivo local deve ser movido para que um update possa trazer o outro arquivo e o conflito seja resolvido.

File had conflicts on merge : A mescla automática falhou, o conflito deve ser resolvido.

Unknown : O CVS não conhece o arquivo. Ele ainda não foi adicionado ou é um temporário.


3-26


Consultando Históricos

• O comando log exibe históricos de arquivos– A saída de log é, para cada arquivo, um cabeçalho com algumas informações e a lista de revisões do histórico• O cabeçalho dá a última revisão, etiquetas e outros detalhes• Para cada revisão, é mostrado seu número, quem a criou e quando e a mensagem de log (o comentário do check-in)

• cvs [op_glob] log [op_cmd] [arquivos...]– As opções específicas op_cmd são vistas adiante– O argumento são zero ou mais arquivos (diretórios)

• O comando rlog é equivalente, mas pode ser usado sem uma cópia de trabalho

Uma das funcionalidades mais importantes de um sistema de controle de versões é a capacidade de consultar históricos. Isso inclui verificar quantas revisões um arquivo já teve, quando foram criadas, quem as produziu e qual o propósito de cada uma. No CVS, o comando que exibe históricos de arquivos é log. Além de informações sobre os históricos em si, log exibe um cabeçalho com informações sobre a última revisão, etiquetas aplicadas sobre o arquivo e detalhes como o modo default de substituição de palavras-chave.

O formato do comando log é mostrado neste slide. Opções de comando são vistas adiante. O argumento para log é formado por zero ou mais arquivos, que são examinados e têm seus históricos impressos na saída do comando. O comportamento recursivo do CVS se aplica também a log.

O CVS disponibiliza também o comando rlog, que tem as mesmas opções e o mesmo funcionamento de log, com a diferença que pode ser usado sem uma cópia de trabalho. Para que rlog encontre o repositório, é preciso que a opção global –d seja usada ou a variável de ambiente $CVSROOT esteja definida.


3-27


Principais Opções de log

• As opções de comando mais usadas com log são:– -d datas: Faz o log somente de revisões criadas no intervalo especificado por datas, cujo formato é:• d1<d2 ou d2>d1 = datas entre d1 e d2• <d ou >d = datas anteriores ou iguais a d• >d ou d> = datas posteriores ou iguais a d• d = a data d (exatamente)

– -rrevisões: Faz o log somente de revisões dadas por revisões, tem o seguinte formato (não pode haver espaço depois de –r):• r1:r2 e r1::r2 = revisões entre r1 e r2 (:: exclui r1)• :r e ::r = revisões anteriores a r (:: exclui r)• r: e r:: = revisões posteriores a r (:: exclui r)

– -N: Não imprime a lista de etiquetas aplicadas sobre os arquivos– -h: Imprime só as informações do cabeçalho, não as revisões

Este slide mostra as principais opções usadas com o comando log. As opções –d e –r especificam quais revisões serão incluídas na saída e são úteis quando um arquivo tem um histórico muito longo e estamos interessados somente em algumas revisões.

A opção –N faz com que a lista de etiquetas não seja impressa e é útil em projetos onde muitas etiquetas são aplicadas (quando há, por exemplo, liberações muito freqüentes). A opção –h faz com que somente o cabeçalho seja impresso, não as revisões (útil quando há muitas revisões e estamos interessados somente nas etiquetas, por exemplo).


3-28


Verificando Quem Alterou o Quê

• O comando annotate imprime os arquivos especificados anotando, para cada linha:– Qual foi a última revisão que a modificou– Quem foi o autor da revisão e quando ela foi criada

• cvs [op_glob] annotate [op_cmd] [arquivos...]– op_glob são opções globais e op_cmd, opções de comando; as mais usadas são –D data, –r rev e –f

– O argumento é zero ou mais arquivos a anotar

• O comando rannotate é equivalente, mas pode ser usado sem uma cópia de trabalho

O comando annotate é útil para identificarmos quem modificou cada linha de um arquivo e quando (em qual e revisão e em que data). O formato do comando é dado no slide. As opções de comando mais comuns com annotate são aquelas que especificam revisões por data (-D) ou etiqueta/número de revisão (-r) e a opção –f, que força a seleção de uma revisão. Zero ou mais arquivos podem ser especificados e o comportamento recursivo se aplica.

Existe também o comando rannotate, que pode anotar arquivos sem a dependência de uma cópia local. Como ele opera direto sobre o repositório, é preciso usar a opção global –d ou definir a variável $CVSROOT.


3-29


Listando Arquivos no Repositório

• É possível listar arquivos e diretórios no repositório, com ou sem uma cópia local

• cvs [op_glob] ls [op_cmd] [arquivos...]– op_glob são opções globais, op_cmd são opções de comando, as mais importantes são:• -l: Formato longo: exibe todos os detalhes dos arquivos• -R: Habilita o comportamento recursivo (não é o default)• -D data e -r revisão: seleciona revisões por data e revisão

– O argumento são zero ou mais arquivos ou diretórios; se nenhum for especificado, lista a raiz do repositório

• ls só lista arquivos que estão presentes na cópia local• O comando rls é equivalente, não usa uma cópia local e émais usado, pois inspeciona diretamente o repositório

Os comandos ls e rls são bastante novos no CVS (apareceram na versão feature 1.12). Eles funcionam como o comando ls do UNIX, só que operam sobre um repositório CVS. São úteis para listar todos os módulos presentes no repositório (lembre-se que checkout –c mostra apenas os módulos existentes em modules) e para se verificar quais arquivos estão sob um módulo sem precisar fazer um checkout.

As opções de ls e rls não seguem o padrão dos demais comandos CVS, pois tentam imitar as opções do comando ls do UNIX. Por exemplo, -l é usada para mostrar a saída no formato longo (todos os detalhes), enquanto que –R habilita o comportamento recursivo, que não é o default. As opções mais importantes são listadas no slide.

O comando rls é mais útil, pois lista diretamente os arquivos no repositório, sem a necessidade de uma cópia local.


3-30


Lab3-4: Listando Modificações

• Verificar o status de arquivos em diversas situações já experimentadas– Adição– Remoção– Arquivo desatualizado– Mescla e conflito

• Inspecionar o histórico de revisões de um arquivo• Anotar as alterações em um arquivo

Neste lab, consultaremos o status de arquivos que passaram por operações como remoção, adição e mescla. Listaremos históricos de arquivos, controlando as opções da saída e anotaremos um arquivo, identificando quem alterou o quê. Veja os materiais do aluno.


3-31


Inspecionando Diferenças

• Um recurso importante oferecido pelo CVS é a capacidade de comparar duas revisões

• Para essa função existe o comando diff• cvs [op_glob] diff [op_cmd] [arquivos...]

– op_glob são opções globais, op_cmd são opções do comando, as mais usadas são as que selecionam revisões (vistas adiante)

– O argumento são zero ou mais arquivos (e diretórios); para cada arquivo, as revisões selecionadas pelas opções são comparadas

• Há várias opções de formatos de saída para diff• O CVS possui também o comando rdiff

– Recebe opções similares às reconhecidas por diff– Funciona diretamente no repositório, sem cópia local– Produz a saída no formato usado pelo utilitário patch

Um dos comandos mais úteis do CVS é diff, que exibe as diferenças entre duas revisões de um mesmo arquivo. As opções de diff são usadas para selecionais quais revisões serão comparadas e para configurar o formato da saída (há vários formatos). Veremos essas opções nos próximos slides.

O CVS também oferece o comando rdiff, que funciona diretamente no repositório, sem a necessidade de uma cópia local. A saída de rdiff é produzida no formato usado pelo aplicativo patch do UNIX, cuja função é incorporar correções ou pequenas alterações a conjuntos de arquivos.


3-32


Opções Mais Usadas com diff

• Seleção de revisões e controle de palavras-chave:– O default é mostrar as diferenças entre a revisão-base e a cópia do arquivo na área de trabalho

– -D data e -r revisão: Especificam uma ou mais datas e revisões (etiquetas ou números de revisão)• Se uma opção for usada, mostra as diferenças entre a revisão especificada pela opção e a cópia na área de trabalho

• Se duas opções forem usadas, mostra as diferenças entre as revisões especificadas pela primeira opção e a segunda opção

– -k opção-k: Processa palavras-chave de acordo com opção-k• Controle do formato da saída:

– -b: Ignora mudanças formadas por espaços em branco– -C n: Usa o formato de Contexto, com n linhas de contexto– -U n: Usa o formato Unificado, com n linhas de contexto– -y: Usa o formato lado-a-lado

O comando diff tem dois tipos de opções: opções para selecionar as revisões a serem comparadas e opções para controlar o formato da saída. As opções de seleção de revisões já são nossas conhecidas: -D para selecionar revisões em uma certa data e –r para revisões marcadas por uma etiqueta ou identificadas por um número. O comando diff difere dos demais porque pode receber zero, uma ou duas opções especificando revisões. Se nenhuma opção for usada, diff mostra as diferenças entre a última revisão do repositório e a cópia na área de trabalho. Note que a ordem importa: o arquivo 1 (origem) é a revisão do repositório, o arquivo 2 (destino) é a cópia local. Se uma opção –D ou –r for usada, diff mostra as diferenças entre a revisão especificada (1) e a cópia de trabalho (2). Por fim, se duas revisões forem especificadas, diff mostra a diferença entre a que aparece em primeiro na linha de comando (1) e a que aparece em seguida (2).

As opções de controle de saída são várias (na verdade, dezenas). Consulte um guia para conhecê-las todas. Uma opção comum é –b, que faz com que sejam ignoradas mudanças formadas por somente espaços em branco. Outras opções muito usadas são aquelas que selecionam o formato da saída. Como veremos adiante, diff tem um formato default, que é o mesmo do aplicativo UNIX chamado diff. Outras 3 opções permitem a seleção de formatos alternativos: -C para o formato de Contexto, -U para o formato Unificado e –y para o formato lado-a-lado. Veremos que formatos são esses no próximo slide.


3-33


Formatos de Saída de diff

• Normal (default)– Cada bloco de diferenças mostra que alteração ocorreu, linhas do arquivo 1 (precedidas por <) e do arquivo 2 (precedidas por >)

• Contexto– Começa com um cabeçalho, seguido por blocos indicando o que foi mudado e algumas linhas de contexto em torno

• Unificado– Similar ao formato de Contexto; os caracteres que indicam as modificações são diferentes

– É um padrão usado por algumas ferramentas

• Lado-a-lado– Os arquivos são exibidos lado-a-lado, com linhas correspondentes dispostas na mesma linha da saída

– É o mais conveniente para inspeção visual

O tipo de saída default do comando diff é o formato normal. Abaixo os diversos formatos são explicados brevemente.

Normal. O formato normal é composto por um ou mais blocos de diferenças, cada bloco no seguinte formato:

tipo_diferença

< linha_arquivo_1

---

> linha_arquivo_2

Contexto. O formato de contexto começa com um cabeçalho com duas linhas, no seguinte formato:

*** nome_arquivo_1 data_modificação_arquivo_1

--- nome_arquivo_2 data_modificação_arquivo_2

Em seguida vêm os blocos de diferenças, mostrando uma área na qual os arquivos diferem e com o seguinte formato:

***************

*** intervalo_linhas_arquivo_1 ****

c linha_arquivo_1

--- intervalo_linhas_arquivo_2 ----

c linha_arquivo_2

Unificado (unidiff). O formato unificado começa com um cabeçalho com duas linhas, no seguinte formato:

--- nome_arquivo_1 data_modificação_arquivo_1

+++ nome_arquivo_2 data_modificação_arquivo_2

Em seguida vêm os blocos de diferenças, mostrando uma área na qual os arquivos diferem, no seguinte formato:

@@ intervalo_linhas_arquivo_1 intervalo_linhas_arquivo_2 @@

c linha_arquivo_1_ou_2

Lado-a-lado. Produz uma listagem dos dois arquivos lado-a-lado, destacando as diferenças, no seguinte formato:

[linha_arquivo_1] c [linha_arquivo_2]

Nos formatos Contexto, Unificado e Lado-a-lado, o caractere c indica o tipo de diferença entre os arquivos, tais como: linha inserida, linha removida ou linha alterada.


3-34


Lab3-5: Comparando Revisões

• Comparar:– A revisão na cópia local contra sua revisão-base– A revisão na cópia local contra uma revisão arbitrária– Duas revisões arbitrárias, na ordem inversa e direta

• Utilizar os formatos:– Normal– Contexto– Unificado– Lado-a-lado

Este lab exercita o comando diff e suas diversas opções para a seleção de revisões e controle do formato da saída.


3-35


Palavras-Chave

• O mecanismo de palavras-chave permite que informações sobre revisões sejam incluídas nos arquivos– É útil para se consultar informações sem usar comandos como status e log ou fora da cópia local

– Utilizado também para criar, dentro de programas, stringsidentifiquem a revisão compilada

• Palavras-chave mais utilizadas:– $Author$: login do usuário que criou a revisão– $Date$: data de criação da revisão– $Revision$: número da revisão– $Log$: mensagens de log, números de revisões, datas e autores. As mensagens de revisões anteriores são mantidas

• O modo padrão de substituição funciona convertendo $Revision$ para $Revision: 1.3$ ao criar a revisão 1.3

O recurso oferecido pelo CVS, denominado “palavras-chave”, é bastante interessante, pois permite que informações sobre revisões sejam inseridas dentro dos arquivos. Isso ajuda na distribuição de arquivos e para se ter acesso a informações de versão dentro do código de um programa (criando-se strings na linguagem de programação que contêm as palavras-chave).

As principais palavras-chave oferecidas pelo CVS são descritas neste slide. A substituição funciona adicionando “:” e a informação entre os “$”. Futuras conversões substituem a informação anterior, exceto com a palavra-chave $Log$, que sempre adiciona informações.

Adiante veremos com maior detalhe como controlar a substituição de palavras-chave usando as opções-k com comandos tais como update, checkout, diff e export.


3-36


Controlando a Substituição de Palavras-Chave

• Queremos controle sobre a substituição quando:– Temos um arquivo binário e não queremos corromper o conteúdo– O arquivo vai ser exportado do CVS e queremos manter somente a informação dada pela palavra-chave, não seu nome

– Estamos comparando revisões e queremos evitar que as palavras-chave gerem diferenças artificiais

• Principais modos de controle de substituição (opções-k):– -kkv: É o modo default: gera nome e valor da palavra-chave– -kb: Inibe a expansão de palavras-chave, bem como a conversão de fins-de-linha – usado com arquivos binários

– -kk: Gera apenas o nome da palavra-chave – útil ao se executar o comando diff e realizar mesclas

– -ko: Inibe a expansão de palavras-chave e converte fins-de-linha– -kv: Gera apenas o valor da palavra-chave – útil ao se exportar

O CVS permite que a substituição de palavras-chave seja controlada, em cenários como a presença de um arquivo binário, exportação de revisões e comparação de revisões. Os modos de substituição de palavras-chave são chamados opções-k, pois são especificados pela opção –k, usada em diversos comandos, como checkout, update e diff. Os principais modos são exibidos neste slide. Vale lembrar que as opções-k são aderentes, isto é, uma vez especificadas com checkout ou update, permanecem válidas para posteriores execuções dos comandos na cópia local, mesmo que não sejam usadas explicitamente na linha de comando. O comando status é útil para se verificar as opções aderentes em uma cópia local


3-37


Lab3-6: Usando Palavras-Chave

• Inserir palavras-chave em um arquivo• Verificar os resultados da substituição padrão• Controlar a substituição de palavras-chave

Este lab exercita o uso de palavras-chave. Consulte os materiais do aluno para instruções.


3-38


Especificando Opções Default

• O CVS permite que o usuário especifique opções globais e de comandos que devem ser default

• O arquivo .cvsrc, no diretório home do usuário, é usado para incluir opções default

• Opções de comandos:– Cada linha começa com um nome de comando, seguido de uma ou mais opções daquele comando

– Quando o comando é executado pelo usuário, o CVS inclui, logo após o nome do comando, as opções em .cvsrc

– Exemplos úteis: checkout –P, update –Pd; perigo: remove –f

• Opções globais:– Se a linha começa com o comando cvs, a opção é global– Exemplo útil: cvs –z3; cuidado: cvs –d /cvsrep

Se o usuário não concorda com o comportamento default de alguns comandos do CVS, é possível modificá-los usando um arquivo de configuração. Esse arquivo é o .cvsrc, que deve existir no diretório home do usuário (por exemplo, /home/mneubert no UNIX e C:\Documents and

Settings\mneubert no Windows).

Cada linha desse arquivo é um nome de comando, seguido de uma ou mais opções que o usuário deseja tornar default. Quando aquele comando é executado, o CVS inclui automaticamente essas opções, como se elas fossem especificadas na linha de comando, logo após o nome do comando. Alguns exemplos úteis de linhas a serem adicionadas ao .cvsrc:

checkout –P

update –Pd

diff –b

Se o nome do comando for cvs, a linha especifica opções globais para o CVS. Um exemplo útil para se compactar a comunicação cliente/servidor em redes lentas:

cvs –z3

Curso de CVS - Parte 3 - Uso Básico

Technology

Transcript of Curso de CVS - Parte 3 - Uso Básico