![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a CVS - Slides Parte 3 - Básico
Semelhante a CVS - Slides Parte 3 - Básico (20)
Mais de Marden Neubert
Mais de Marden Neubert (7)
CVS - Slides Parte 3 - Básico
- 1. Uso Básico do CVS Módulo 3 Foco: Autor
Notas do Editor
- 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.
- Este slide mostra nossa agenda para este módulo do treinamento, voltado para o uso básico do CVS.
- 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.
- 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.
- 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 .
- 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 .
- 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 .
- 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.
- 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-linha se 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.
- 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.
- 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.
- 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.
- Neste lab, exercitaremos o comando commit . Veja o arquivo lab-3.doc nos materiais do aluno para maiores detalhes.
- 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 .
- 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).
- 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 arquivo original é 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 .
- 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.
- 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.
- Neste lab, exercitaremos o comando update . Consulte o material do aluno.
- 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.
- 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 .
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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 .
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 .
- 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
- Este lab exercita o uso de palavras-chave. Consulte os materiais do aluno para instruções.
- 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