Curso de CVS - Lab 3

CVS Básico: Laboratório do Aluno Copyright® 2005, Marden Neubert

1

Lab3-1: Submetendo Alterações

Objetivos

Ao final deste lab, você será capaz de: • Criar uma área de trabalho sobre um módulo no repositório. • Alterar cópias locais de arquivos e submeter alterações. • Configurar o editor utilizado pelo CVS. • Forçar a criação de novas revisões no repositório.

Cenário

Neste lab, exercitaremos o comando commit. Usaremos o já conhecido comando checkout para obter uma cópia de trabalho sobre um módulo no repositório. Realizaremos alterações e as submeteremos ao repositório. Como utilizaremos somente comandos do cliente CVS, este lab (e todos os próximos) pode ser executado tanto no Windows como no Linux, com repositórios locais ou remotos.

Tarefa 1: Obter uma cópia de trabalho e submeter modificações

1. Entre no sistema operacional de sua preferência e faça um check-out do projeto places, importado no Lab2-3. Faça isso sob o seu diretório de trabalho, por exemplo, C:\Trabalho ou /home/mneubert/trabalho, no caso do instrutor. Caso já tenha uma cópia local desse módulo, certifique-se de que ela está sincronizada com o repositório (você pode usar o comando checkout para isso). O resultado deve ser similar ao da figura abaixo.

2. Edite o arquivo Country.java, localizado abaixo da raiz do módulo places, no diretório src/java/br/com/portifolioti/places/domain. Substitua a classe HashSet por TreeSet. Isso deve ser feito na linha 3 (import java.util.HashSet) e na linha 8 (... = new HashSet()).

3. Faça um check-in da alteração, sem especificar uma mensagem de log na linha de comando: cvs commit

4. O CVS abrirá o Notepad, pedindo para que seja informada uma mensagem de log. Crie uma linha no Notepad, pois as linhas começando por CVS: são ignoradas. Insira o comentário: “Estou usando TreeSet no lugar de HashSet”.


2

5. Feche o Notepad. Ele perguntará se o arquivo deve ser salvo. Observe a localização do arquivo, ele é um temporário criado pelo CVS. Diga que “Sim”. A alteração será propagada para o repositório. O CVS imprime na saída de commit o caminho do arquivo RCS (o histórico) alterado pela operação, o número da revisão anterior e da nova revisão.

6. Observe os números de revisão. Como estamos trabalhando no tronco, os números têm apenas duas partes, separadas por um ponto. Como vimos ao importar fontes, ramos derivados têm numerações mais complexas.

7. Edite o arquivo State.java, no mesmo diretório que Country.java. Faça a mesma alteração, substituindo HashSet por TreeSet. Isso deve ser feito na linha 3 (import java.util.HashSet) e na linha 7 (... = new HashSet()).

8. Vá à raiz do módulo, o diretório C:\Trabalho\places, no caso deste exemplo, e execute: cvs commit –m “Estou usando TreeSet no lugar de HashSet”. A saída deve ser similar a:

9. Observe o funcionamento recursivo de commit. O comando procura por alterações em todos os subdiretórios da cópia local e encontra a alteração em State.java. A nova revisão é criada no repositório e, como usamos a opção –m, o editor não é chamado.


3

Tarefa 2: Forçando o check-in de revisões

1. Volte ao diretório src/java/br/com/portifolioti/places/domain e force um check-in do arquivo City.java, usando a opção –f para commit. cvs commit –m “Nova revisao sem modificacoes” –f City.java Note que uma nova revisão foi criada, mesmo que o arquivo não tenha sido modificado.

Tarefa 3 (Opcional): Escolhendo novos números de revisão

Esta tarefa é opcional e, se realizada, deve ser feita no cliente Linux, pois o CVSNT não suporta a opção de linha de comando –r para commit. 1. Vamos agora forçar a mudança do número de revisão de todos os arquivos no módulo para 2.0,

pois 2 é o número da última liberação principal do projeto places. Vá para a raiz do módulo e chame commit com os seguintes parâmetros: cvs commit –m “Registro da liberacao 2” –r 2.0 Observe que é criada uma nova revisão, numerada 2.0, para cada arquivo dentro do módulo.

2. Tente fazer o commit de um arquivo especificando uma revisão mais baixa do que 2.0. Vá ao diretório onde se encontra o arquivo City.java e execute: cvs commit –m “Um teste” –r 1.5 City.java

3. Observe que o CVS retornará um erro, dizendo que o número de revisão especificado é muito baixo e que ele deve ser maior do que 2.0.


4

Lab3-2: Atualizando a Cópia Local

Objetivos

Ao final deste lab, você será capaz de: • Atualizar uma cópia local com as revisões mais recentes. • Criar e remover opções aderentes á cópia local. • Reverter uma alteração feita no repositório. • Presenciar um cenário de mescla automática com sucesso. • Resolver um conflito causado por alterações fora de sincronia com o repositório.

Cenário

Neste lab, conheceremos melhor o comando update. Veremos como utilizá-lo para introduzir opções aderentes na cópia local e como removê-las. Faremos reversão de uma alteração incorreta e lidaremos com mesclas e conflitos.

Tarefa 1: Atualizar a cópia local com uma opção aderente

Já vimos vários exemplos de atualização com as últimas revisões do repositório. Veremos agora uma atualização com uma opção de data (-D), que é aderente à cópia local. 1. Vá à raiz do módulo places. Verifique as datas de atualização do arquivo report.properties,

localizado no diretório src/java. Observe a data da revisão 1.2 desse arquivo (criamos essa revisão em um laboratório do módulo 2). Atenção: as datas estão no fuso horário GMT. Vamos selecionar uma data logo após a criação dessa revisão.


5

2. Atualize o módulo usando uma data entre a criação da revisão 1.2 e da revisão 1.3. Utilize a opção –D para update e escreva a data no mesmo formato exibido por log, com a diferença que será preciso escrever “+0000” ao final, para indicar que o fuso horário usado é GMT. cvs update –D “2005/12/10 17:52+0000” Outra possibilidade seria escrever a data como “2005/12/10 15:52+0200”, indicando que o horário indicado está 02:00h depois de GMT, como o horário brasileiro de verão. Execute também o comando status para verificar as informações sobre o arquivo na cópia local. Veja a saída abaixo.

3. Algumas observações importantes. Note que o arquivo encontra-se atualizado (“Up-to-date”) em relação ao repositório, mesmo existindo lá uma opção mais recente, a 1.3. Perceba que a “Sticky Date” está definida e seu valor é a data que usamos com update. Execute novamente update, sem parâmetros, e veja que nenhuma atualização ocorre.

4. Tentaremos agora realizar o check-in de um arquivo com a opção de data presente na cópia local. Edite qualquer arquivo, por exemplo, Plan.java, no diretório src/java/br/com/portifolioti/places/domain, colocando um comentário antes da declaração da classe. Tente realizar um check-in e veja que ocorre um erro. Não é possível efetuar um check-in com uma data aderente na cópia local.

5. Limpe as opções aderentes na cópia local. Vá à raiz do módulo e execute: cvs update –A


6

6. Observe que o arquivo report.properties foi novamente atualizado, com a revisão mais recente no repositório (assim como City.java). O arquivo Plan.java, que foi editado mas cujo check-in falhou, permanece modificado na cópia local.

Tarefa 2: Reverter uma alteração

Veremos agora como reverter uma alteração já submetida ao repositório. 1. Volte ao diretório domain e efetive a alteração no arquivo Plan.java. Uma nova revisão foi

criada, neste exemplo, o número é 1.2. Em seguida, reverta a alteração usando a alternativa combinando as opções –r e –p. Observe a saída abaixo.

2. Desafio: faça agora uma nova reversão, voltando com o comentário removido, e usando a opção –j. Descubra como montar a linha de comando. Responda: o que fez esse comando?


7

Tarefa 3: Realizar mesclas na atualização

Nesta tarefa, veremos uma situação em que uma mescla ocorre com sucesso. Já vimos anteriormente outro cenário no qual ocorre um conflito. 1. Crie uma nova cópia local para o módulo places. Use, por exemplo, um diretório places2:

cvs –d /cvsrep checkout –d places2 places 2. Edite o arquivo City.java, alterando o método toString. Por exemplo, altere a linha

return getName() + ", " + state; para que ela fique assim: return getName() + " - " + state;

3. Faça o check-in do arquivo, como visto abaixo.

4. Na cópia original, edite o mesmo arquivo, inserindo um comentário antes do nome da classe: /** * Esta classe representa uma Cidade. */ public class City extends Place {

5. Faça o check-in do arquivo. Como visto abaixo, ocorrerá um erro. Faça o update para atualizar a cópia local. Veja a saída de update. A mescla foi feita com sucesso, pois as alterações estão distantes no arquivo. Inspecione o resultado (opcionalmente, chame o comando status para verificar o estado do arquivo) e se tudo estiver OK, faça o check-in.


8

Lab3-3: Movimentando Arquivos e Diretórios

Objetivos

Ao final deste lab, você será capaz de: • Adicionar novos arquivos e novos diretórios ao CVS. • Abortar a adição de um arquivo. • Ressuscitar um arquivo removido. • Mover arquivos entre diretórios e remover diretórios.

Cenário

Neste lab, aprenderemos como movimentar arquivos e diretórios e propagar essas alterações para o repositório.

Tarefa 1: Adicionar um arquivo em um novo diretório

1. Vá ao diretório src dentro do módulo places e crie um diretório test. Crie um arquivo chamado test.txt dentro do diretório test, com um conteúdo qualquer. Tente adicionar este arquivo a partir desse diretório – veja (figura adiante) que ocorrerá um erro, pois o diretório test ainda não foi adicionado (não possui o subdiretório CVS).

2. Volte ao diretório src e adicione o diretório test e o arquivo test.txt; você pode usar o mesmo comando para adicionar ambos. Veja que o diretório CVS foi criado e o arquivo test.txt foi programado para adição. Não faça o commit ainda.


9

Tarefa 2: Cancelar a adição de um arquivo

1. Você irá agora cancelar a adição do arquivo test.txt. Volte ao diretório test e apague o arquivo test.txt. Execute o comando remove. A adição será cancelada e nenhum registro ficará no repositório. Veja a saída abaixo.

Tarefa 3: Cancelar a remoção de um arquivo

1. Vamos cancelar a remoção antes da execução de remove. Apague o arquivo places.csv do diretório src/java. Cancele a remoção com o comando update.

2. Vamos cancelar a remoção após a execução de remove e antes de commit. Apague novamente o arquivo places.csv. Execute o comando remove. Cancele a remoção com o comando add. Veja que o arquivo foi ressuscitado e a revisão anterior foi restaurada.

Tarefa 4: (Desafio) Cancelar a remoção de um arquivo após commit

1. Vamos cancelar uma remoção após a execução de commit. Apague novamente places.csv. Execute remove e, em seguida, commit. Veja abaixo que uma nova revisão é criada (a revisão morta, ou dead), mas seu número não é exibido na saída de remove.

Tarefa 5: Mover arquivos entre diretórios

1. Mova todos os arquivos terminados em “.bat” do diretório bin para o diretório lib, na raiz do módulo. Use o comando remove para apagá-los da origem e commit para confirmar.

2. No diretório lib, use add para adicionar os arquivos e commit para confirmar. Veja a saída dos comandos abaixo. Note que as novas revisões criadas têm a numeração 1.1, do tronco. As revisões anteriores, numeradas 1.1.1.1, não estão conectadas à nova numeração.


10

Tarefa 5: (Opcional) Renomear um diretório

1. Deseja-se renomear o diretório lib para jars. Para isso, copie o diretório lib, criando o diretório jars. Apague os arquivos em lib, remova-os com remove e execute commit. Vá ao diretório jars, adicione os arquivos usando add e confirme com commit. Use comentários que deixem clara a movimentação.

Dica: Os arquivos *.jar, que serão movidos, são binários. Lembre-se que eles foram importados usando-se o embalador *.jar –k ‘b’. Para adicionar esses arquivos sob o diretório jars, não se esqueça de informar para o comando add que eles são binários, usando a opção –k.


11

Lab3-4: Listando Modificações

Objetivos

Ao final deste lab, você será capaz de: • Consultar o status de um arquivo na cópia local. • Listar o histórico de revisões de um arquivo. • Verificar que revisão alterou cada linha de um arquivo.

Cenário

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

Tarefa 1: Consultar status de arquivos

Vamos repetir algumas das operações feitas anteriormente e consultar o status dos arquivos durante o processo. 1. Verifique o status de um arquivo durante um processo de remoção. Volte ao arquivo places.csv

e repita os passos feitos no lab anterior. Veja o status dele logo após ser apagado da cópia local: é “Needs Checkout”, pois um update trará todo o conteúdo do arquivo para a cópia local.

2. Use o comando remove e verifique o status de places.csv. É “Locally removed”, pois a remoção ainda não foi efetivada com commit.


12

3. Cancele a remoção com add e verifique que o arquivo volta a estar atualizado.

4. Crie novamente o arquivo test.txt, e verifique o status do arquivo recém-criado. O CVS não o conhece, portanto, não há muitas informações a exibir.

5. Adicione test.txt e peça seu status. Verifique que ele está adicionado pela cópia local, mas ainda não tem um número de revisão. Após conferir a saída, apague o arquivo e use remove para cancelar a adição.

6. Verifique os status que surgem diante de uma mescla. Altere um arquivo, por exemplo, ReportPrinterTest.java, no diretório src/java/br/com/portifolioti/places, a partir de uma cópia local. Faça, por exemplo, uma alteração no final do arquivo. Vá a outra cópia local e verifique seu status. Veja que o CVS indica que enviará um patch, uma pequena atualização do arquivo.


13

7. Faça uma outra alteração nesse arquivo, a partir dessa cópia. Para evitar um possível conflito, se você fez antes uma alteração ao fim do arquivo, faça agora uma alteração no início dele. Verifique que o status mudou e indica que uma mescla deve ser feita.

8. Faça uma atualização e a mescla ocorrerá. Ela provavelmente funcionará e a saída será a seguinte. Veja que o arquivo agora se encontra desatualizado e um commit precisa ser feito. Faça o check-in e crie a nova revisão.


14

9. Volte à cópia local original e altere o arquivo na mesma linha que foi alterada na outra cópia. Perceba que essa alteração certamente criará um conflito. Faça o update e verifique o status do arquivo. Um conflito foi gerado, como mostrado pela saída do comando status.

Tarefa 2: Listar o histórico de revisões de um arquivo

Usando um arquivo para o qual já criamos algumas revisões, vamos verificar seu histórico. 1. Vá ao diretório src/java/br/com/portifolioti/places/domain, e peça o histórico do arquivo

City.java, informando a opção –h, para obter somente o cabeçalho da saída. Observe que vemos informações sobre o arquivo no repositório e as etiquetas criadas com suas importações.

2. Peça agora o log do mesmo arquivo, porém usando a opção –N, para não exibir as etiquetas. Observe que todo o histórico de revisões é exibido, juntamente com as mensagens de log. A saída de log pode ser bem extensa, portanto algumas vezes ela tem que ser direcionada para um arquivo.


15

Tarefa 3: Anotar as modificações em um arquivo

Usando o mesmo arquivo da tarefa anterior, verificaremos que revisão (e quem e quando) alterou cada uma de suas linhas. 1. No mesmo diretório onde a tarefa anterior foi executada, chame o comando annotate sobre o

arquivo City.java. Observe a saída a seguir. Para cada linha da última revisão do arquivo, mostram-se a última revisão que a alterou, o nome do autor e a data (somente o dia).


16


17

Lab3-5: Comparando Revisões

Objetivos

Ao final deste lab, você será capaz de: • Selecionar revisões para a comparação. • Escolher um formato de saída para a comparação. • Usar opções para controlar a comparação.

Cenário

Neste lab, compararemos revisões usando comando diff e suas diversas opções.

Tarefa 1: Selecionar revisões para a comparação

1. Edite o arquivo City.java, usado no lab anterior. Faça as seguintes alterações sobre ele: inverta a ordem dos métodos getState e contains (deixe contains antes de getState, respeitando as linhas em branco) e mude o método toString, usando uma vírgula em vez de um traço.

2. Execute o comando diff sem usar opções. O CVS compara a cópia local com a última revisão no repositório. Veja a saída a seguir, que usa o formato padrão de saída de diff. Como o método getState “desceu”, ele foi indicado como tendo sido removido (o caractere d indica deleted) das linhas 15 a 18 e adicionado (o caractere a indica added) nas linhas 19 a 22. A linha alterada no método toString (número 32) aparece como modificada (o caractere c indica changed).

3. Observe a saída acima e veja que os trechos marcados com “<” são do arquivo no repositório (o arquivo origem da comparação, ou o arquivo 1) e os trechos marcados com “>” são do arquivo na cópia local (o arquivo destino, ou o arquivo 2). A ordem dos arquivos é muito importante na comparação.

4. Compare agora a cópia local contra a revisão 1.2 de City.java. Para isso, use apenas uma opção –r para diff. Perceba que a saída indica que um comentário foi adicionado (trocando-se uma linha em branco pelas 3 linhas de comentário) e que a troca de ordem dos métodos ocorreu. A alteração no método toString fez com a que a cópia local voltasse a ficar como a revisão 1.2, portanto essa diferença não existe aí.


18

5. Compare agora a revisão 1.4 contra a 1.2. Atenção à ordem das opções –r. Queremos as modificações feitas a partir da revisão 1.2 até a revisão 1.4. Portanto, 1.2 deve aparecer na linha de comando antes de 1.4. Veja a saída abaixo.

6. É possível também comparar revisões na ordem cronológica inversa. Por exemplo, quais as modificações que deveriam ser feitas para sairmos da revisão 1.4 e chegarmos na 1.2? Execute o comando invertendo a ordem das revisões. Veja a saída a seguir. Ela mostra as alterações no sentido exatamente inverso ao das alterações na figura anterior.


19

Tarefa 2: Escolher outros formatos de saída

1. Faça a mesma comparação entre cópia local e revisão-base, porém escolhendo o formato de saída de Contexto, com uma linha de contexto. Veja a saída abaixo.

2. Veja os caracteres que indicam remoção, adição e modificação. Observe que uma linha foi adicionada antes e depois de cada diferença, para mostrar seu contexto. Faça o teste com 3 linhas de contexto. O programa patch precisa de ao menos 2 linhas para executar.

3. Faça a mesma comparação usando agora o formato Unificado, que também usa linhas de contexto ao redor da modificação. Especifique também apenas uma linha de contexto. Veja a saída a seguir.


20

4. Note que a saída é mais compacta, mas também mais complicada. A alteração é representada como uma remoção e uma adição. O formato Unificado foi criado para ser lido por ferramentas.

5. Selecione agora o formato lado-a-lado. Use –W 80 para ajustar a largura. Veja a saída abaixo.


21

Lab3-6: Usando Palavras-Chave

Objetivos

Ao final deste lab, você será capaz de: • Inserir palavras-chave em um arquivo. • Controlar a substituição de palavras-chave.

Cenário

Neste lab, treinaremos o uso de palavras-chave com o CVS.

Tarefa 1: Inserindo palavras-chave e verificando os resultados

1. Considere o arquivo City.java, usado no lab anterior. Provavelmente ele conterá as modificações pendentes feitas naquele lab; faça antes um check-in daquelas modificações. Modifique o comentário ao início da classe, da seguinte forma: /** * Esta classe representa uma Cidade. * @version $Revision$ */ Faça um novo check-in do arquivo. Abra-o novamente e verifique seu conteúdo. Provavelmente ele será como a seguir (o número da revisão pode estar diferente).

2. Perceba que o CVS substituiu a palavra-chave $Revision$ por seu nome e seu valor. 3. Faça uma nova modificação em City.java, por exemplo, modificando o método toString ao

final da classe. Faça novo check-in e verifique os resultados com a figura abaixo.

Tarefa 2: Controlando a substituição de palavras-chave

1. Vamos comparar as duas últimas revisões do arquivo City.java criadas no lab anterior. Faça um diff, usando a opção –C 1, para selecionar o formato de saída de contexto. Você pode usar duas opções –r para selecionar explicitamente as revisões, ou aproveitar que a revisão 1.7 já está na cópia local e usar somente uma opção –r. O resultado deve ser similar à figura adiante. Observe que a alteração gerada pela palavra-chave foi interpretada como uma alteração.


22

2. Para evitar que esse tipo de modificação gere diferenças espúrias, vamos usar os modos de substituição de palavras-chave para inibi-las. Use a opção –k k para fazer com que as palavras-chave não incluam seu valor, somente seu nome. Veja que diferença agora é somente a modificação no método toString.

Curso de CVS - Lab 3

Technology

Transcript of Curso de CVS - Lab 3